Agent context
PagerDuty models
3 SQL models that turn the raw PagerDuty tables into the reports people ask about. Deploy them in Weld and your agent queries the definitions behind every number.
How the set is built
- 4Raw tables
- 4Staging
- 3Core
- 3Analytics
Staging cleans each raw table once, core holds the logic, and analytics is the table dashboards and agents read.
- Incident response dailyIncident volume and response times per service and team: PagerDuty's Service Performance and Team Performance reports, by day. Mean time to acknowledge (MTTA), mean time to resolve (MTTR), escalations, auto-resolves and the interruption load on responders.grain: one row per incident creation day (UTC) x service x team x urgency x priority · 1 raw table
- Open incidentsEvery incident that is not resolved yet, with its age: the Incidents page filtered to Open, for a backlog dashboard or an alert on incidents left acknowledged for days.grain: one row per open incident (current state as of the last sync) · 1 raw table
- Responder load dailyHow much incident work lands on each responder: incidents assigned to them, acknowledged by them and resolved by them. The per-person view of PagerDuty's Responder report, for spotting the people carrying the on-call load.grain: one row per incident creation day (UTC) x user · 4 raw tables
- Weld or dbt
- The same SQL in both dialects. Sync the folder with GitHub Sync, or copy the dbt models into your project.
- Check before you rely on it
- Reconcile a month against PagerDuty's own reports first. Each model's notes say what the synced data can and can't support.
Connect PagerDuty.
Your agents start with context.
Sync PagerDuty to your warehouse, deploy these models, and query them from Claude, Cursor or ChatGPT over MCP. Free for 14 days, no credit card.