Two New Tabs That Tell You What Likely Broke, Before RCA Even Runs
A hand-curated library of 12 common webhook failure patterns matches every failed delivery in microseconds — likely cause and suggested fix appear before any AI call. Alongside it, a new Recent Changes tab pulls every audit log entry for the route/destination/transform involved in the failure over the last 14 days.
The 3AM Question
Your phone buzzes. A webhook is failing in production. You open the event debugger. The Failure RCA card is loading. You sit there for 6 seconds wondering: was this a config change I made today, or is it just a destination outage?
That 6 seconds happens a lot. Today we're shipping two pieces of context that answer it instantly.
Failure Pattern Library
Every failed delivery now runs through a small library of hand-curated patterns. They're matched synchronously on the backend — no Claude call, no waiting — and surfaced as cards on the failed delivery itself.
The 12 patterns we shipped cover the cases we see most often:
- Signature rejection (400/401/403 with "invalid signature" in the error) → rotated secret
- 401 generic → expired credentials
- 403 → IP allowlist mismatch or role change
- 404 → endpoint moved or URL typo
- 405 → wrong HTTP method
- 408/504 → destination too slow
- 429 → destination rate-limiting us
- 5xx → destination outage or payload-shape issue
- Connection refused → destination unreachable
- DNS failure → hostname unresolvable
- TLS / certificate → cert expired
- Schema validation → payload shape changed
Each match produces a card with a title, a hypothesis (here's what we think happened), and a suggested fix (here's what to try first). Multiple patterns can match — they stack in order.
The point isn't to replace RCA. The point is to give you something to look at while RCA is loading, and to make the 80% case ("yeah, that's our secret rotation") resolve without any AI call at all.
Recent Changes Tab
Right next to the existing tabs, there's a new Recent Changes tab on the event debugger. It pulls every audit log entry for the entities involved in this event — the routes that fired, the destinations they targeted, and the transforms attached to those routes — over the last 14 days.
Each entry shows:
- The action (
destination_updated,transform_updated,route_filter_changed, etc.) - The entity type and id
- The actor (user or system)
- A timestamp
- Expandable JSON details of what specifically changed
- A deep link to the entity's edit page
If you see "destination_updated by you, 8 minutes ago" right above a failed delivery, that's almost always the cause. The tab badge shows the count so you can scan the event header without clicking in.
Why These Two Together
The pattern library tells you what kind of failure this looks like. The recent-changes tab tells you what changed recently that could have caused it. Together they answer the 3am question — "is this me or them?" — without you having to think.
RCA still runs in the background and gives you the AI-validated synthesis. But by the time it lands, you usually already know.
On the Backend
The pattern library lives in api/src/utils/failurePatterns.ts — 12 entries with match criteria (statusEquals / statusIn / statusRange / errorIncludes / responseBodyIncludes), category, hypothesis, suggested fix. The matcher is pure and synchronous — runs in microseconds per delivery.
Recent changes ride on a new stored procedure fn_audit_log_for_entities(org, entity_ids[], since, limit) and a corresponding index on audit_log (organization_id, entity_id, created_at DESC) — cheap lookups even with a large audit table.
Both ship today on every plan that already had the event debugger.