Webhook monitoring for every endpoint you deliver to
Svix records every webhook you send, every delivery attempt, and the response each customer endpoint returned. You get alerts when an endpoint starts failing, and your customers get their own delivery logs, so “did you send it?” has an answer without a support ticket.
Five signals that show whether webhook delivery is healthy
Track them per endpoint, not only as a global average: one customer whose endpoint has been down for days barely moves an overall success rate.
Monitoring tells you when delivery degrades. For how Svix keeps it from degrading in the first place, see webhook reliability.
Delivery success rate
Track first-attempt success and eventual success after retries separately. If first-attempt success falls while eventual success holds, the receiver is flapping or timing out and retries are covering for it.
Svix reports delivered, failed, and pending counts per endpoint for any time range, plus attempt successes and failures over time, through the API.
Failing endpoints
An error rate tells you something is wrong. A list of failing endpoints tells you which customers are affected, since when, and with what status code.
Svix sends you message.attempt.failing on a message's fourth failed attempt, with the endpoint, the customer's app, and the last status code.
Delivery latency
Measure the time from when you send an event to its successful attempt, at the 95th percentile. A rising p95 points to a backlog, or to slow receivers tying up delivery capacity.
Svix records the response time of every attempt, and the message.attempt.log operational webhook sends attempt timings in batches you can load into your own metrics.
Retries and exhausted messages
Retries are normal. Messages that run out of retries are not: any nonzero count is an incident for that endpoint, and it needs a replay once the endpoint is fixed.
Svix retries on a fixed schedule that spans about a day, sends message.attempt.exhausted when a message fails for good, and can recover every failed message since a point in time.
Disabled endpoints
An endpoint that fails for days should be switched off instead of retried forever, but then that customer stops receiving events and may not notice. Each one needs someone to reach out.
Svix disables an endpoint after five days of failures and sends you endpoint.disabled. It can also email your customer directly, with a link to your webhooks page.
Alert on what someone has to act on
Svix sends you operational webhooks as delivery changes state. Route them to Slack, your incident tool, or your own code, and give each one a response:
message.attempt.failing: A message failed its fourth attempt. Post it to a channel so someone sees it.message.attempt.exhausted: Retries ran out and the message failed. Open an incident for that endpoint and plan the replay.endpoint.disabled: The endpoint was switched off after days of failures. Contact the customer, or let Svix email them.message.attempt.recovered: A message that triggered an alert was delivered. Close the loop.
{
"type": "endpoint.disabled",
"data": {
"appId": "app_2KWPBgL1Afxdpx2AI54p",
"appUid": "customer_123",
"endpointId": "ep_2KWPBgL1Afxdpx2AI54p",
"failSince": "2026-10-02T09:41:00Z",
"trigger": "automatic"
}
}Every message, every attempt, every response
When a customer asks about a webhook, the answer is already recorded. Svix stores each message and each delivery attempt with its request and response, so your team can investigate any delivery after the fact.
Attempt history
Every attempt keeps the URL, status code, response body, response time, and whether it was scheduled or triggered by hand.
Filter to the problem
List attempts by endpoint or by message, filtered by status, status code class, event type, channel, tag, or time range.
Resend and recover
Resend one message, recover every failed message since a point in time, or replay messages an endpoint never received.
Per-endpoint stats
Pull delivered, failed, and pending counts for any endpoint and time range from the API, without running your own aggregation.
Attempt data in your tools
The message.attempt.log operational webhook sends batches of attempt metadata, including status, status code, attempt count, and timings, to your own endpoint.
OpenTelemetry streaming
On Enterprise, Svix streams a trace for every delivery attempt to Datadog, New Relic, Coralogix, or any platform that accepts OpenTelemetry.
Let customers see their own deliveries
Webhooks are one-way, so customers usually hear about failures from you, or you hear about them from a support ticket. The App Portal embeds in your dashboard and gives each customer visibility into their own endpoints. From it, they can:
- See the messages sent to each of their endpoints, filtered by event type and date.
- Inspect delivery attempts and replay past webhooks.
- Resend a single message, or recover everything that failed since a given time.
- Send test events to an endpoint before relying on it.
- Get an email when one of their endpoints is disabled.
“The observability that we now have for our customers, our support teams, and our internal development team has been a major unlock for us. We knew we couldn't dedicate the engineering time required to build this at the level we required, but now that we have it we can't live without it.”
Svix's own uptime is public
Live status for every region is on our status page, and uptime SLAs are 99.999% on Enterprise, 99.99% on Professional, and 99.9% on Basic.
Startups get $12,000 in free credits
Incorporated in the last three years and raised $7M or less? Get $1,000 a month in Svix credits for a year, plus hands-on onboarding from our team. Companies in the current YC batch get $50,000.
What is webhook monitoring?
Webhook monitoring is tracking whether the webhooks you send reach your customers' endpoints: delivery success rate, failing and disabled endpoints, delivery latency, and messages that run out of retries. It alerts you per endpoint when delivery degrades, and keeps a record of every attempt so you can say what happened to any single event.
What's the difference between webhook monitoring and webhook observability?
Monitoring watches known signals and alerts when they change, like an endpoint failing or a message running out of retries. Observability is being able to answer new questions after the fact, like what one customer's endpoint returned last Tuesday. Svix covers both: operational webhooks for alerts, and stored attempts, stats, and OpenTelemetry traces for investigating.
Which webhook metrics should we alert on?
Alert on what a person has to act on: a message that exhausted its retries, an endpoint that was disabled, and a sustained drop in first-attempt success for an important customer. Single failed attempts are noise, since retries exist to absorb them. Watch p95 delivery latency for backlogs.
How does Svix alert us when webhooks fail?
Through operational webhooks sent to an endpoint you choose: message.attempt.failing on the fourth failed attempt, message.attempt.exhausted when retries run out, message.attempt.recovered when a message that triggered an alert gets through, and endpoint.disabled when an endpoint is switched off. Subscribe to them in the Operational Webhooks section of the dashboard.
Can our customers see their own webhook logs?
Yes. Embed the App Portal in your dashboard, and each customer sees the messages sent to their endpoints, inspects delivery attempts, replays past webhooks, and recovers failed ones without opening a support ticket.
Can we send webhook delivery data to Datadog or another observability platform?
On Enterprise, OpenTelemetry streaming sends a trace for every delivery attempt to Datadog, New Relic, Coralogix, Grafana, or any platform that accepts OpenTelemetry. You can also subscribe to the message.attempt.log operational webhook, which delivers attempt metadata in batches you can load into your own metrics.
