AI Incident Triage with PagerDuty and Mezmo

It's 2:47 a.m. PagerDuty fires. Normally you'd find the alert, guess which service is involved, open your observability tool, and start writing a query.

Instead, you ask an AURA agent to triage it. It pulls the alert, searches the last five minutes of telemetry for correlated errors, and writes a timeline with a root cause hypothesis and next steps.

The interesting part isn't that an agent can do this. It's how little it takes to set up, and what you control while it runs. The whole agent is one short config file you can read in two minutes.

TL;DR

• What it is: An open-source incident triage agent that connects PagerDuty and Mezmo, then investigates an alert the way an experienced on-call engineer would.
• What you get back: A timeline, a root cause hypothesis, and next steps, with timestamps and links back to the source data.
• What you need: A PagerDuty API token, a Mezmo API key, and an API key for your model provider.
• Time to first run: About 10 minutes with the AURA install script.
• Cost: AURA is free and open source (Apache 2.0). You pay only for your own model usage.
• Source: examples/complete/incident-response-mezmo.toml

What this example does

This example configures a single AURA agent with two tool connections:

1. PagerDuty, for incidents, on-call schedules, and escalations.
2. Mezmo, for telemetry analysis and pipeline monitoring.

Both connect through their official MCP (Model Context Protocol) servers. No custom integration code.

When you hand the agent an incident, it follows a three-step triage workflow:

1. Identify the triggering alert and affected services in PagerDuty.
2. Search Mezmo telemetry for correlated errors and anomalies.
3. Summarize the findings as a timeline, a root cause hypothesis, and next steps.

Two defaults keep it focused:

• It investigates the last five minutes of telemetry and alerts unless you ask for a different window.
• It's capped at 10 reasoning turns, so it reports what it found instead of looping on a dead end.

Who it's for

Jobs to be done

• On-call engineer: When I get paged for a service I don't know well, I want the relevant alert and telemetry context gathered for me, so I can start fixing instead of searching.
• SRE lead: When incidents hit different people on the rotation, I want triage to follow the same steps every time, so the quality of the first response doesn't depend on who's on call.
• Platform engineer: When my team asks for an AI assistant for SRE work, I want a production-tested starting point in config, so I'm not writing and maintaining agent framework code.
• Engineering leader: When I evaluate AI for operations, I want to test it on real incidents with low setup cost and clear boundaries, so I can decide on evidence instead of a vendor demo.

Pain points it removes

• Tab-switching under pressure. Triage usually means bouncing between the paging tool, the observability tool, and a runbook. The agent does the correlation across both systems.
• Cold starts on unfamiliar services. The agent starts from the alert and works outward. You don't need to know which signals matter before you begin.
• Inconsistent first response. Every investigation follows the same three steps and produces the same output shape.
• Summaries nobody has time to write. The output is already a timeline with sources, ready for the incident channel or the postmortem.
• Unverifiable answers. The agent is instructed to include timestamps and link back to source data, so you can check its work.

What it replaces, and why it's better

The value it drives

• Faster time to first hypothesis. One request starts the investigation, instead of someone hunting for the right query.
• Lower on-call load. Less time spent gathering context means less fatigue across the rotation.
• Consistent incident records. Timestamped, sourced summaries make handoffs and postmortems easier.
• Low-cost evaluation. Open source, no procurement, and you can measure it against your own incidents.

What to measure in a pilot: time from alert to first hypothesis, how often the hypothesis matches the confirmed root cause, and on-call engineer feedback on summary usefulness.

Why AURA

• Production-tested. AURA started as Mezmo's internal harness for operating our own SaaS. Our engineering and SRE teams still use it in production, and it powers thousands of agent sessions each month in Mezmo's hosted platform.
• Runs inside your security boundary. Deploy in your own infrastructure, including air-gapped environments, with control over model, tool, storage, and telemetry destinations.
• The whole agent is reviewable config. Models, prompts, tools, and guardrails live in TOML you can version, diff, and review in a pull request.
• Model-agnostic. OpenAI, Anthropic, Bedrock, Gemini, Ollama, or OpenRouter. Switching is a config change.
• Human approval when you want it. Gate any tool that changes state behind webhook or in-chat approval, failing closed on denial or timeout.
• Traceable end to end. Every request, model turn, and tool call can be exported as OpenTelemetry traces.

Start from where you are

• Use Datadog instead of Mezmo? Start with incident-response-datadog.toml. Same workflow, Datadog metrics and traces.
• Use Checkly for synthetic monitoring? See incident-response-checkly.toml.
• Standardized on a different model? Change the [agent.llm] block. Minimal configs for each provider are in examples/minimal.
• Want a human to approve actions? Add a [hitl] block. See hitl-webhook.toml for approvals routed to an on-call engineer.
• Running Kubernetes? The Kubernetes SRE quickstart coordinates cluster inspection and metrics specialists.
• Just want to look? Read the config below. No install required.

Look inside the config

The agent's behavior is defined in plain language, in the config file itself:

[agent]
name = "Incident Response Agent"
system_prompt = """
You are an incident response agent with access to PagerDuty and
Mezmo. Follow this triage workflow:

1. Identify the triggering alert and affected services via PagerDuty.
2. Search logs in Mezmo for correlated errors and anomalies.
3. Summarize findings: timeline, root cause hypothesis, and next steps.

Unless the user explicitly specifies a different time window, investigate
logs and alerts from the last 5 minutes by default.
Always include timestamps and link back to source data.
"""
turn_depth = 10

Want it to check your runbooks first, or post to Slack when it's done? Edit the steps and add the connection. Your team's triage process becomes a reviewable file.

Try it in three steps

1. Install AURA (Linux or macOS):

curl -fsSL https://raw.githubusercontent.com/mezmo/aura/main/scripts/install.sh | bash

2. Set your credentials:

export OPENAI_API_KEY="sk-..."
export PAGERDUTY_API_TOKEN="..."
export MEZMO_API_KEY="..."

3. Download the example and run it:

curl -fsSLO https://raw.githubusercontent.com/mezmo/aura/main/examples/complete/incident-response-mezmo.toml
aura --config incident-response-mezmo.toml

More detail: AURA example configs.

Then ask it about an open incident: "Triage the latest high-urgency PagerDuty incident."

FAQ

Does the agent change anything in my systems?

This example's workflow is investigative: it reads alerts and searches telemetry. To guarantee that any tool capable of changing state requires sign-off, add a [hitl] approval block.

Does my telemetry leave my environment?

AURA sends prompts and tool results only to the model providers and services you configure. Run it in your own infrastructure with a self-hosted model (for example, Ollama) to keep everything in-house. See the security and data-handling model.

Which models does it support?

OpenAI, Anthropic, AWS Bedrock, Google Gemini, Ollama, and OpenRouter.

What does it cost?

AURA is free under the Apache 2.0 license. You pay your model provider for usage.

Can I connect it to Slack, Jira, or our runbooks?

Yes. AURA works with any compatible MCP server, including Slack, Jira, Confluence, Notion, GitHub, and more. See the integrations list.

Next steps

• Engineers: Clone the example and run it against a real incident.
• Leads and managers: Share this page with your on-call rotation and pick one service to pilot.
• Everyone: Join the AURA Slack community to ask questions and see what other teams are building.