# Reliability

> What WhaBuzz promises about delivery and speed, what each promise means for your code, how we prove it, and the live figures.

Canonical: https://docs.whabuzz.com/reliability/

## The promises {#promises}

| Promise | What it means for your code | How we prove it |
|---|---|---|
| Meta's webhook gets our `200` only after the event is stored | If Meta saw a `200`, the event exists in your log. Nothing Meta delivered to us is acknowledged and then lost. | A staging test kills the event store mid-accept and checks that no `200` is sent for an unstored event. |
| Retry ladder: +30 s, 1 m, 2 m, 5 m, 10 m, 20 m, 40 m, 1 h, then hourly up to 24 h. After 5 straight failures the endpoint's circuit opens. After 24 h a delivery is marked `dead` and we email you. | A slow or broken endpoint recovers by itself. Return any non-2xx and we try again; you never need your own retry queue for our deliveries. | A test sink in a failing mode receives attempt 4 at about 3.5 minutes. A sink that always answers `500` reaches `dead` at 24 h and the email arrives. |
| Replay any event for your whole retention window (30, 90, 180 or 365 days) | A bug on your side is recoverable. Replay after the fix and the event arrives again with the same `id`, `seq` and `dedupe_key`, plus a new delivery attempt id. | A test replays a 31-day-old event on a 90-day tenant and compares the identifiers. |
| Delivery SLO: 99.9% of events reach a healthy endpoint within 60 s. Inbound own time p99 under 30 ms. | Events arrive quickly and our own processing adds little to your latency. "Own time" excludes time spent waiting on Meta or on your endpoint. | The figures below, measured from production metrics, plus your own numbers in the console. |
| At-least-once delivery, never silently dropped. Every envelope has `dedupe_key` and `seq`. | You may see an event twice, never zero times. De-duplicate on `dedupe_key`; spot a gap by watching `seq`. | A CI replay checks that every field Meta sent is present in `raw`. Gap detection is documented with code. |
| Meta's errors, verbatim | When Meta rejects a request you see Meta's own error body under `error.meta`, unchanged, next to ours. | CI sends known-bad requests through the sandbox and compares Meta's body byte for byte with ours. |

See also: [Webhooks](https://docs.whabuzz.com/guides/webhooks.md) for the retry and replay mechanics, [Errors](https://docs.whabuzz.com/errors.md) for the `error.meta` shape, and [Retention](https://docs.whabuzz.com/guides/retention.md) for the replay window.

## Live figures {#live}

> **Production ramp-up in progress.** WhaBuzz went live on 16 October 2026 and traffic is still low, so most requests reach a cold Durable Object and a single slow request sets the p99. The figures below are real and unadjusted; expect them to settle as production volume arrives.

The figures are live on the HTML page, https://docs.whabuzz.com/reliability/, and come from the public endpoint `GET https://api.whabuzz.com/v1/reliability` (no authentication; cached for 5 minutes; `windows["24h"]` and `windows["30d"]`, each entry `{ id, name, target, value, unit, status }`). The targets:

- Inbound ack, Meta POSTs answered without a 5xx: >= 99.95%
- Inbound own time p50: < 8 ms
- Inbound own time p99: < 30 ms
- API own time p99: < 30 ms warm, < 120 ms cold
- First forward starts after Meta POST arrives: p95 < 50 ms, p99 < 250 ms
- Delivered to a healthy endpoint within 60 s of receipt: 99.9%
- api.whabuzz.com availability: 99.95%
- Key revocation effective within 60 s: 100%

`status` is `pass`, `fail`, `no_data` or `not_measured` (not yet published).

## Look up a request {#requests}

Every response carries a `request_id`. Look it up with [`GET /v1/requests/{request_id}`](https://docs.whabuzz.com/reference.md#tag/requests/GET/v1/requests/{request_id}) or in the console's Logs page. See [Errors](https://docs.whabuzz.com/errors.md).