Webhook delivery health for your integrations

Most integration outages are silent. Slack stops posting, Stripe stops syncing, GitHub stops opening issues — and the first sign is usually a customer asking why their order wasn't acknowledged. The webhook deliveries page is the dashboard that turns "silent" into "obvious."

The health dot on each integration card

Open /settings/integrations. Every connected provider has a card, and every card has a dot in the top-right corner:

• Green — last 100 webhook deliveries succeeded, with normal latency.
• Yellow — at least one failure in the last 100 deliveries, or median latency above 2 seconds. Clear after 24 hours of clean traffic.
• Red — current error rate above 10% over a 5-minute window, or no deliveries received for a provider that should be active. This is the page you want to be on.
• Grey — never delivered. Either the integration is brand-new or its webhook URL never received traffic; check the provider's setup.

The dot is computed from real delivery records, not a heartbeat ping, so a green dot means real customer events have flowed through in the last hour.

Per-provider deliveries page

Click any card and you land on the deliveries page for that provider. It's one row per webhook attempt:

• Timestamp and event type
• HTTP status, latency, and the size of the payload
• A redacted payload preview, expandable to the full body
• Retry attempts (we retry failed deliveries with exponential backoff up to 6 times over 24 hours)

The default view filters to failures, because that's what you came for. Toggle to show successes if you're verifying that a specific event landed.

What failed deliveries mean

Three patterns cover almost everything:

• 401 / 403 from us — the signing secret rotated on the provider side and didn't get updated in Ochre. Re-paste the secret in the integration card.
• 5xx from us — a real bug or a transient. We retry, you don't have to. If 5xx persists across retries, file a ticket.
• Timeout — the provider sent the event but we didn't acknowledge in time, usually because the event triggered an expensive workflow. The retry will normally land. If timeouts are a steady fraction of your traffic, ping us — we'll widen the timeout window for that provider.

Debugging the loud cases

If a card has gone red, the deliveries page filtered to failures will tell you which event types are breaking. If they're all the same type — e.g. only customer.subscription.updated from Stripe — the cause is almost always a payload change on the provider side. Open one failure, expand the payload, compare against the schema we expected. The expected schema is linked at the top of every provider's deliveries page.

Who can see this

Deliveries pages are admin-facing because the payloads contain raw customer data. Owner and admin roles can read; agents and light agents can't.