# Write a Weekly Incident Summary From Datadog

Yes. Each week an agent reads Datadog incidents and triggered monitors and writes incidents.md with durations, services, repeat offenders and trends.

[Run this on Rush](https://cloud.getrush.ai/run/weekly-incident-summary/datadog/).

## What the agent does

The agent reaches Datadog through the Datadog MCP server in the Rush connector catalog, `https://mcp.datadoghq.com/api/unstable/mcp-server/mcp`, which searches logs, metrics, traces, monitors, incidents and dashboards on the US1 site. One `POST /me/connections` with `"type": "mcp"`, the name `datadog`, that URL and `"auth": {"mode": "oauth"}`, followed by the Datadog sign-in, makes it nameable on any run.

It reads the incidents created in the last 7 days and the 7 before that. For each incident it records the severity, the state, the services and teams it lists, when it was detected and resolved, and the resolution or summary the commander wrote. Duration is resolved minus detected; an incident still open is listed with its age and marked open, not given a made-up end.

Monitors are the second half. The agent reads which monitors triggered during the week, how many times each one fired, and on which service, then sorts them by count. A monitor that fired often without any incident attached is a candidate for tuning; one that fired before an incident was declared is worth noting as the early signal. It keeps those two kinds apart in the report.

Finally it compares the two weeks: incident count by severity, total and median time to resolve, and the services that appear in both. Read only means it declares, updates and mutes nothing; it writes `incidents.md` in its sandbox.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "Use the Datadog connection to read incidents and triggered monitors from the last 7 days and from the 7 days before. Write incidents.md with: a table of this week's incidents with severity, state, affected services, detected and resolved times, duration and resolution summary; the monitors that fired most often with their service and count, marking those with no linked incident; services with incidents in both weeks; and a comparison with the week before (count by severity, total and median time to resolve). Read only: declare, update or mute nothing.",
  "connections": [
    "datadog"
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

The session returns `incidents.md` as an artifact. It opens with a short comparison block (this week against last), then the incident table, then the monitor list, then the repeat services. An engineering manager can walk into the weekly reliability review with it as the agenda.

Each row came from an incident or monitor read the agent made, and every call with its answer sits in the session's transcript. Before the review, check the resolution summaries for incidents whose commander left none, since the agent reports those as missing rather than guessing, and look at the noisy monitors with whoever owns them.

## Run it on every Friday afternoon

An automation with a schedule trigger in a Project starts the run on a `cron` such as `0 15 * * 5` in your `timezone`, so the summary is written before the week ends and the review on Monday starts prepared. Each run looks back 14 days for the comparison and reports on the last 7.

Set a webhook URL on the key and Rush POSTs `run.completed` with the `session_url` when the turn finishes. A small handler can read the session, fetch `incidents.md` from its artifacts and post it to the reliability channel or attach it to the meeting invite.

## Why run it on Rush?

The weekly incident summary is usually written by whoever is on call, from memory and several Datadog tabs, on the day they are most tired. The agent reads the incidents and monitors through the connection in its own sandbox and writes the same summary every week in the same shape, so weeks can be compared.

Its numbers are traceable: every read is in the session's transcript, and the run changes nothing in Datadog. Teams that split services across Datadog organizations can run one session per organization at the same time, up to the key's concurrent run limit.

## Frequently asked questions

### Do we need Datadog Incident Management for this?

The incident section does, since it reads Datadog incidents. Without it, change the prompt to report on triggered monitors only; the monitor half of the report works on its own.

### How is time to resolve measured?

From the incident's detected time to its resolved time, as Datadog records them. Open incidents are listed with their age and left out of the averages, and the report says how many were left out.

### Can it include postmortem follow-ups?

If they are in Datadog as incident tasks or notes, yes; add that to the prompt. If they live in Jira or Linear, name that connection on the run too and ask the agent to list open follow-ups per incident.

### How does it find repeat offenders?

It counts incidents and monitor triggers per service across both weeks. A service with incidents in both weeks, or a monitor among the most frequent in both, is listed as repeating, with the incidents that put it there, so the review can ask whether last week's fix held.