What the agent does
The run needs no repository. It reaches Datadog through Datadog's own remote MCP server, https://mcp.datadoghq.com/api/unstable/mcp-server/mcp, which the Rush connector catalog lists for the US1 site; an organization on another Datadog site adds its own address as a custom server. You connect it once with POST /me/connections {"type": "mcp", "name": "datadog", "url": "https://mcp.datadoghq.com/api/unstable/mcp-server/mcp", "auth": {"mode": "oauth"}}, open the authorize_url it returns while signed in to the console, and from then on any run that names datadog in connections can call Datadog as you.
The agent starts by listing what the server's tools can read and every SLO it can find for the last 30 days. For each one it records the name, the type (metric-based or monitor-based), the target and the time window Datadog evaluates it over, then reads the achieved value and the error budget remaining for the same 30 days. Where an SLO's own status is not something the tools return directly, it works from what sits behind it: the good and total event queries of a metric-based SLO, or the uptime of the monitors behind a monitor-based one, and it marks those rows as computed rather than read.
Burn rate is the share of budget spent divided by the share of the window that has passed, so an SLO that has used half its budget halfway through the month burns at 1. The agent computes it per SLO and shows its working beside the number. For every SLO that has spent more than half its budget, it goes looking for the cause in the same window: incidents declared against the service, monitors on the service that triggered, and when they fired and recovered. It lists those with their times so a reader can line them up against the budget curve.
The prompt says read only, and the agent calls no tool that creates, mutes or edits anything. It writes slo.md in its sandbox, with a summary table first, one section per SLO that is at risk, and a short note on any SLO it could not read and why.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the Datadog connection to read every SLO in the organization for the last 30 days. Write slo.md with each SLO's name, type, target, achieved value, error budget remaining and burn rate, with how the burn rate was computed. For each SLO that spent over half its budget, list the incidents and triggered monitors on its service in that window, with their start and recovery times. Mark any value you computed from monitors or metrics rather than read from the SLO itself. Read only: create, mute or change nothing in Datadog.",
"connections": [
"datadog"
]
}- 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.
- 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.
- 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
What comes back is slo.md as an artifact on the session, with a download link from the session read that works for an hour. It opens with one table, a row per SLO: target, achieved, budget left, burn rate and a status word (healthy, at risk or breached). Below it, each SLO that spent more than half its budget gets its own section with the incidents and monitors that fired on that service in the window, so the reliability review starts from the few SLOs that need a conversation.
Every number in the report came from a tool call the agent made, and the session's transcript keeps each call with its arguments and output. A reviewer who doubts a burn rate can open the transcript at the call that read it. Before taking the report into a review, check that every SLO you expected is in the table (the agent sees only what the connected account can see), and read the notes on any row marked as computed.
Run it on every first day of the month
An automation with a schedule trigger in a Project starts this run on a cron expression in your timezone, such as the first of each month at 08:00, with the Project's connections. A job on your own server can do the same by sending this request on that day. Each run reads the 30 days before it, so the report always covers the month that just closed.
Give the API key a webhook URL and Rush POSTs run.completed with the session_url when the turn ends. Your server reads the session, takes the slo.md link from its artifacts and posts it to the channel or document the reliability review uses.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
An SLO review usually starts with someone clicking through each SLO in the Datadog UI and copying numbers into a doc, and the incidents that spent the budget live on another screen. On Rush the agent does the clicking through tool calls in its own sandbox, puts the SLO numbers and the incidents side by side, and writes them down in one file.
The report comes with its evidence: every query and its answer is in the session's transcript, so a disputed number can be traced to the call that produced it. One run per Datadog organization or per team can go at once, up to the key's concurrent run limit, and nothing runs on anyone's laptop.
Frequently asked questions
Can the agent change anything in Datadog?
The prompt tells it not to, and the transcript shows every tool it called, so you can check. For a hard limit, connect Datadog with an account whose role can only read. The agent can do only what that account can do.
Our Datadog organization is not on US1. Does this work?
Yes, with one change. The catalog entry points at the US1 address; connect your site's MCP address as a custom server with POST /me/connections and name it on the run the same way.
What if some SLOs are monitor-based and others metric-based?
The report handles both. The agent records each SLO's type and reads or computes its achieved value from what backs it, and it marks computed values so they are not mistaken for numbers Datadog reported.
Can I get it as a Confluence or Notion page instead of a file?
Yes. Name that connection on the run too and change the prompt's last step to create the page there. The report text stays the same; only where it lands changes.