Skip to content

Incident Response Context Builder

Example prompt: "When a PagerDuty incident is created for our production service, pull the last 3 deployments from GitHub, search our runbook in Notion for the affected service, and post a context summary to #incidents on Slack."

How to automate incident context gathering with GloriaMundo

The Problem

When an on-call engineer gets paged at 2am, the alert itself rarely has enough context. They need to check what was deployed recently, look up the service's runbook, and piece together whether anyone else has seen similar issues. This triage phase can take 10-15 minutes of frantic tab-switching before any actual debugging begins — and that is assuming the engineer knows where all the information lives.

How GloriaMundo Solves It

We build a workflow triggered by a PagerDuty webhook whenever an incident is created. An integration step fetches the last three deployments from GitHub for the affected repository, including commit messages and authors. A second integration step searches your Notion workspace for the relevant runbook page based on the service name from the alert. An LLM step combines everything — the alert details, recent deploy history, and runbook excerpts — into a structured context summary. Finally, an integration step posts that summary to your #incidents Slack channel, threaded under the alert notification. Glass Box preview lets you verify the summary format and check that the right runbook was matched before the workflow goes live.

Example Workflow Steps

  1. Trigger (webhook): Fires when a new PagerDuty incident is created.
  2. Step 1 (integration): Fetch the last 3 deployments from GitHub for the repository associated with the affected service — commit SHAs, messages, authors, and timestamps.
  3. Step 2 (integration): Search Notion for the runbook page matching the service name from the alert payload.
  4. Step 3 (LLM): Combine the alert details, recent deployments, and runbook excerpts into a structured incident context summary — what changed recently, who to contact, and initial troubleshooting steps.
  5. Step 4 (integration): Post the formatted context summary to #incidents on Slack.

Integrations Used

  • PagerDuty — source of the incident alert and service metadata
  • GitHub — recent deployment history and commit information
  • Notion — runbook and service documentation lookup
  • Slack — receives the formatted context summary for the on-call team

Who This Is For

On-call engineers and SRE teams who want to reduce the time between receiving an alert and starting meaningful debugging, particularly in organisations with multiple services and frequent deployments.

Time & Cost Saved

Manually gathering context for an incident typically takes 10-15 minutes of checking deployment logs, searching documentation, and cross-referencing alerts. For a team handling 5-10 incidents per week, that is 1-2 hours of triage time saved. The workflow runs a few integration and LLM steps per incident, costing a handful of credits each time.