Reliability

How it's built to stay up

Ping Bouncer is designed so that an alert is either accepted and kept, or clearly refused. We don't silently drop it.

• Accept, then write. An alert is written durably before we acknowledge it to the sender.
• Refuse loudly. If we can't accept an alert, we return a server error, so senders that retry will resend it.
• Queued delivery. Deliveries retry with backoff (10 seconds, 30 seconds, then 90 seconds). After the last attempt they move to a dead-letter queue and show as failed in your events log, where you can see them.
• No double delivery by design. Each delivery has an idempotency key per destination. Some destinations may still receive a repeat after a retry, and we're working on closing that gap.

Where we run

Ping Bouncer runs on Cloudflare's global network, so there's no single region we depend on. We don't currently offer a choice of region for where your data is processed. See the privacy policy for more.

Status and incidents

We're setting up a public status page, hosted outside our own infrastructure so it stays reachable during an outage. Until it's live, we don't publish an uptime figure. Once it is, we'll publish our availability there, along with incident history.

Service levels

Our Terms of Service say the service comes without an uptime guarantee unless you have a separate written agreement. We'll publish a service-level target here once the status page is live and we can measure it.

If you have a question

For a reliability question during an evaluation, email hello@pingbouncer.com. For anything security-related, see the security page.