10 Webhook Reliability Metrics Every Platform Engineer Should Track

Every webhook system reports two metrics: success rate and volume. Neither predicts a failure until after customers file tickets. The reliability metrics that actually matter are further downstream and more specific. This is the set to track, with definitions, thresholds, and instrumentation notes for each.

Track all ten. Missing any one of them leaves a blind spot that will eventually surface as an incident.

What are the ten metrics you actually need?

Not five. Not fifteen. Ten, because that is the smallest set that covers delivery, retry, endpoint health, and per-customer economics.

The one everyone misses is signature verification failure rate. It goes silent for months, then rotation goes wrong and you find out from three customers at once.

How do you define first-attempt success rate correctly?

The percentage of deliveries where the very first POST to the consumer endpoint returns a 2xx within the connection timeout window. Not "eventually succeeded." Not "succeeded within the retry ladder." First attempt only.

The correct denominator is total delivery attempts started, not events emitted. If an event fans out to five endpoints, that is five attempts. If any of them 429s or times out, it is a failure on that endpoint's attempt but does not affect the others.

Segment by consumer, not just across the fleet. A 95% aggregate can hide one customer at 60%. Segmenting reveals which specific integration is degraded.

What is the right retry-to-success ratio?

Total retry attempts divided by total successful deliveries. If your retry ladder never fired, the ratio would be 1.0. In practice, you want 1.3 to 2.0.

• Below 1.3. Either your first-attempt success rate is unusually high (great) or you are not retrying enough (bad, check for 5xx events silently dead-lettering).
• 1.3 to 2.0. Healthy. Retries are catching the transient failures they should.
• Above 2.5. You are retrying too aggressively or your consumer fleet has systemic issues. Check for a specific customer dragging the average up, or a retry curve that is too dense in the first few minutes.

The metric is a check on the retry ladder itself. If the ratio drifts week-over-week, something changed in the ladder or in the consumer fleet.

Why is time-to-degraded-detection the most underrated metric?

Because it is the difference between an incident that pages your on-call and an incident that never happens.

An endpoint that starts failing has a natural progression: first few attempts fail, retry backoff triggers, more attempts fail, the endpoint eventually enters a degraded state where you rate-limit it aggressively or route it to a slow queue. The question is how fast you make that decision.

• Under 60 seconds. Excellent. A dying endpoint gets isolated before it consumes shared queue capacity.
• 60 to 300 seconds. Acceptable. Some collateral damage but not incident-level.
• Above 5 minutes. You are running degradation detection on a scheduled sweep, which is too slow. Convert to event-driven detection triggered on rolling failure count per endpoint.

The instrumentation is a per-endpoint sliding window of recent responses, checked on every attempt, with a state transition to degraded when a threshold is crossed (typically 5 failures in 60 seconds).

How do you measure endpoint availability without noise?

Percentage of hours in the last 7 days where the endpoint returned at least one 2xx. Not per-attempt. Per-hour.

The per-hour bucketing is what makes this useful. A per-attempt metric on a low-volume endpoint that gets one event per day can look like 100% or 0%, neither of which is meaningful. Per-hour bucketing turns availability into a comparable score across low and high volume endpoints.

Weekly window is the right length. Daily is too jittery, monthly hides genuine degradation. Publish this on the customer-facing dashboard so they see their own availability trend.

What alerting thresholds actually matter?

Do not alert on raw success rate. Alert on error budget burn.

Define an SLO: "99.95% final delivery over rolling 28 days." The error budget is the allowed failure volume for that period. Every failed delivery consumes budget. Alert when burn rate exceeds a threshold that would exhaust the budget before the window closes.

The right burn-rate alerts:

• Fast burn. Consuming 5% of monthly budget in the last hour. Page immediately.
• Slow burn. Consuming 10% of monthly budget over the last 6 hours. Ticket to daytime.
• Endpoint-scoped burn. A single customer consuming 20% of their per-customer budget in an hour. Notify the customer, not your team.

Volume-aware alerting stops the noise that direct threshold alerts create.

What about metrics on the ingest side?

If your platform also receives webhooks from third parties, track a parallel set on ingest.

• Inbound signature verification rate. Should be at or near 100%. Drops indicate rotation lag or spoofing.
• Deduplication hit rate. Percentage of inbound events dropped as duplicates. 1 to 5% is normal. Above 10% means the source is over-retrying.
• Ingest-to-processed latency. Time from receiving to your consumer processing. If this grows, your downstream is bottlenecked.
• Replay volume. Events replayed after a bad deploy or a failed handler. Track weekly.

Ingest metrics are the ones that tell you when Stripe or your vendor is having a bad day, which is often before Stripe's status page updates.

What actually matters

The mistake to avoid is treating webhook reliability as a single number reported on a dashboard nobody looks at. Reliability is a set of related metrics, each of which measures a different failure mode, and each of which needs its own alert threshold. Ship all ten, put five on the customer-facing dashboard, keep the other five on your internal SRE surface, and set alerts on error budget burn rather than raw thresholds. Teams that instrument this way find issues from graphs before customers find them from broken integrations. Teams that do not, do not.