Triage a new incident
When the page fires, PromptQL writes the briefing — affected service, owner, on-call rotation, suspicious deploys, the matching runbook, and a starting timeline — before responders type their first question.
The outcome
Without PromptQL, the first 10 minutes of an incident are spent gathering context — who's on call, what service is this, who owns it, what changed recently, is there a runbook — across five different systems. With PromptQL, that briefing is ready in 30 seconds and responders land in a channel that already knows what's going on.
How to recreate it
- Connect the systems that hold incident context as integrations: your pager (PagerDuty, Opsgenie, etc.), the service catalog, the on-call rotation source, your deployment system, and the wiki where runbooks live.
- In your incidents room, when a page fires, paste the incident ID into a fresh thread and ask PromptQL to “help manage it.”
- PromptQL pulls the incident, service, owner, on-call, recent deploys, runbook, and a starting timeline together into a single briefing post.
- Promote the prompt to an action so the briefing writes itself on every page — “when a Sev-1 or Sev-2 fires, post this briefing in the incident channel.” See Have it take action for the mechanics. Now responders walk in to a thread that already has context, not a blank channel.
- Treat the timeline as the starting point for the post-mortem. PromptQL keeps appending alert events, deploy markers, and human notes as the incident unfolds — when it's over, you export the artifact instead of reconstructing a chronology from Slack scrollback.
Why it works
The first 10 minutes are almost always coordination overhead. Every answer — who's responding, what's affected, what changed — lives in a different system owned by a different team, and every minute spent finding it is a minute the service stays broken.
Pull it together up front. Responders focus on fixing the problem instead of figuring out what the problem is.