Available now
PagerDuty + OnCallReady: AI Incident Response for PagerDuty Alerts
OnCallReady sits upstream of PagerDuty, intercepting automatable incidents before the escalation chain fires — your on-call rotation only wakes up for incidents that genuinely require a human decision.
Replace or augment — your choice
Replace for low-sev
- OnCallReady handles all P3/P4 incidents autonomously
- PagerDuty stays for P1/P2 escalations only
- Dramatically fewer 3 AM pages
- Full audit trail replaces manual incident notes
Augment for all sev
- OnCallReady runs first on every alert
- Resolved = PagerDuty never fires
- Unresolved = PagerDuty escalation proceeds normally
- On-call gets pre-diagnosed incidents with fix attempts noted
How it works
Point your monitoring tools at OnCallReady instead of PagerDuty. When OnCallReady can't resolve an incident, it forwards to your PagerDuty service via Events API v2 with the full diagnostic context already attached.
Monitoring tool fires alert
│
▼
OnCallReady — matches runbook, executes fix
│
├── Resolved ──▶ Post to Slack. PagerDuty never fires.
│
└── Unresolved ──▶ PagerDuty Events API v2
severity: original severity
details: {
attempted_runbook: "disk-full",
actions_run: ["purge_logs", "purge_tmp"],
failure_reason: "disk still > 85% after purge",
diagnostic_context: {...}
}
→ PagerDuty pages on-call with full context
Signal → Action table
| PagerDuty severity |
OnCallReady behavior |
PagerDuty outcome |
| P4 — disk > 90% |
Disk Full Remediation (28s avg) |
Never fires — resolved autonomously |
| P3 — service degraded |
Service Restart & Recovery |
Never fires if recovery succeeds |
| P3 — memory high |
Memory Exhaustion runbook |
Never fires if stabilized |
| P2 — DB pool exhausted |
Attempt DB Connection Pool runbook |
Fires with diagnostic context if runbook fails |
| P1 — production down |
Immediate forward to PagerDuty |
Always fires — no autonomous delay on P1 |
| Any — no runbook match |
Diagnose, capture context, escalate |
Fires with pre-populated diagnostic data |
Setup in 3 minutes
Configure OnCallReady to forward unresolved incidents to your PagerDuty service using Events API v2.
OnCallReady environment variables
# Add to OnCallReady config — enables PagerDuty fallback
PAGERDUTY_ROUTING_KEY=your_pd_integration_key_here
PAGERDUTY_ESCALATE_ON_FAILURE=true
PAGERDUTY_MIN_SEVERITY=P2 # P3/P4 only auto-resolve, never pages
# In PagerDuty: create an Events API v2 integration
# on your existing service. Copy the integration key above.
# Your monitoring tools keep pointing at PagerDuty as backup,
# but add OnCallReady as the primary webhook receiver.
# Result: OnCallReady resolves low-sev, PagerDuty only fires
# for P1/P2 or when autonomous remediation fails.
What stays on-call
OnCallReady doesn't replace your escalation chain — it protects it from noise:
- P1 incidents — always forwarded to PagerDuty immediately, no autonomous delay
- Any incident you configure with
pagerduty_always: true — bypasses OnCallReady entirely
- Security incidents — never auto-resolved, always human-reviewed
- Autonomous action failures — escalated with full context so on-call isn't starting blind
- Incidents during configured maintenance windows — OnCallReady suppresses, PagerDuty stays silent
Related
Most PagerDuty users also use Slack for incident comms. Connect both:
Fewer pages. Same coverage.
Most teams cut P3/P4 pages by 70% within the first week.