Skip to content
Ping Bouncer
The map How it works House rules Integrations Pricing FAQ
Sign in
← Back to Ping Bouncer

Security

For security reviewers. Last updated October 6, 2026

The short version

Ping Bouncer is a small, hosted service with no servers of your own to patch. It receives alerts over HTTPS, matches them against rules you write, and delivers them to destinations you connect. We keep as little as we can, encrypt the credentials you give us, and tell you plainly what we don't have yet.

Architecture

  • Serverless, on Cloudflare's network. There are no VMs or containers for us to patch, and no long-lived servers. Infrastructure is defined in code and deployed through CI.
  • Alerts are accepted at the edge closest to the sender, then written durably before we acknowledge them. If we can't accept an alert, we return an error rather than dropping it, so well-behaved senders retry.
  • Delivery is queued. Failed deliveries retry with backoff, move to a dead-letter queue after the last attempt, and show as failed in your events log. Each delivery carries an idempotency key per destination.

Tenant isolation

  • Each workspace's routing rules are compiled into their own program, separate from every other workspace's.
  • The workspace a request belongs to comes from a verified session or from the endpoint's own secret. It is never taken from a request body.
  • Configuration releases don't contain credentials.

Encryption

  • In transit: TLS for all traffic to and from Ping Bouncer.
  • Secrets we store: destination credentials and endpoint secrets are encrypted at the application layer with keys unique to each workspace. Each value is bound to its record, so a value copied into another workspace won't decrypt.
  • At rest: the underlying storage platforms encrypt data at rest.

Ingest authentication

Each endpoint has its own secret. We store only a SHA-256 hash of it, and compare incoming values in constant time.

Custom code sandbox

Customer-written transforms run in an isolated sandbox. The sandbox has no access to storage bindings, can only make outbound HTTPS requests to an allowlist, and can't reach raw IP addresses.

Access control

Workspaces have admin and member roles. Our own staff access is limited to a short list, and staff don't read alert content unless you ask us to look at specific events. See the privacy policy for details.

Single sign-on (SSO/SAML) is not available today. We'll tell you when it is.

Data handling

Retention periods, what we keep after deletion, and what happens when you close an account are in the privacy policy. Customer-chosen destinations are not our subprocessors. Our full subprocessor list is on the subprocessors page.

Reliability

How the ingest path and delivery are built to stay up, and how we report on it, are on the reliability page.

Compliance status

We are not SOC 2 certified, and we have no audit booked. The infrastructure we run on (Cloudflare and Clerk) is covered by their own SOC 2 Type II reports, which you can request from them. Those reports cover them, not us.

We don't publish a certification date or a pen-test summary yet. If your review needs either, email us and we'll tell you where we are.

Vulnerability disclosure

Report security issues to security@pingbouncer.com. Our contact details are also published at /.well-known/security.txt. We won't take legal action against good-faith research that avoids harming customers or their data, and we'll acknowledge reports promptly.

Incident notification

If we confirm a breach affecting your data, we'll notify affected customers without undue delay, and within 72 hours of confirmation.

Request our security pack

Email security@pingbouncer.com for a pre-filled security questionnaire (a standard one like SIG Lite or CAIQ, or yours), an architecture overview, and our data processing terms as they become available.

Ping Bouncer
Security Reliability Subprocessors Privacy Terms

Made for the people who carry the pager. © 2026 Ping Bouncer