Incident investigation
Know what actually happened — before you get paged
Incidents aren't caused by alerts. They're caused by systems disagreeing — with no clear record of what happened. Transyt is the system of record that incident response depends on.
Transyt's role during incidents
Transyt is not an incident response platform.
It is the system of record that incident response depends on.
PagerDuty tells you who's awake. Transyt tells you what actually happened.
What Transyt owns
- What payload was received
- When delivery was attempted
- Why delivery failed
- When escalation triggered
- When delivery finally succeeded
What Transyt does not own
- Who is on call
- Who acknowledged the alert
- Response time tracking
- Escalation chains
- Incident resolution workflows
What Transyt records — immutably
During an incident, you need facts — not interpretations. Every webhook that passes through Transyt creates an immutable evidence trail.
Exact payload received
The raw webhook body, headers, and query parameters — stored before we return 200 OK.
Signature verification result
Whether provider authentication passed or failed, and why.
Every delivery attempt
Timestamp, response code, response body, latency — for each retry.
Failure reasons
Timeout, connection error, HTTP 500, rate limit — the actual error, not a summary.
Escalation triggers
When thresholds were crossed, what conditions matched, which notifications fired.
Final outcome
Delivered successfully, failed permanently, or replayed manually — with timestamps.
These records cannot be edited or deleted. They exist regardless of what happens downstream.
Escalation with evidence, not just alerts
When delivery failures cross defined thresholds, Transyt escalates with full context attached.
Failure detected
Delivery fails. Retries begin. Each attempt is recorded with full details.
Threshold crossed
After N failures or N minutes — your configured threshold — escalation triggers.
Notification sent
Email, Slack, Discord, or PagerDuty — with the payload, timeline, and a link to investigate.
Evidence preserved
The escalation itself is recorded. Who was notified, when, and what context was attached.
Key distinction: Human acknowledgment does not change event truth. "Resolved" in PagerDuty means someone clicked a button. "Delivered" in Transyt means the webhook actually succeeded.
How Transyt works with PagerDuty
One-way escalation. PagerDuty is a consumer, not a peer.
Transyt notifies PagerDuty
When event failures require human attention, Transyt sends an alert to PagerDuty with full context: payload, delivery history, and a link to the event.
PagerDuty handles response
PagerDuty manages who gets paged, escalation chains, acknowledgments, and response workflows. That's what it's built for.
Transyt remains authoritative
Incident status in PagerDuty does not change event status in Transyt. The evidence stands independent of human workflow.
When the postmortem happens
During audits, postmortems, or disputes — Transyt provides the authoritative timeline, regardless of how incidents were handled downstream.
"What was the original payload?"
Exact bytes received, headers included. No reconstruction, no guessing.
"When did we first know?"
Timestamp of first failure, first escalation, first notification — all recorded.
"Why did delivery fail?"
Actual error messages, response codes, and timing for every attempt.
"Did we eventually deliver?"
Final delivery status with timestamp — or replay record if manual intervention was needed.
Stop guessing what happened
Set up in 5 minutes. Every webhook recorded. Every incident investigated with evidence.
Start free