What the agent does
The run reaches Grafana Cloud through Grafana's remote MCP server, https://mcp.grafana.com/mcp, which the Rush connector catalog lists for searching dashboards, querying Prometheus and Loki, and reading alerts and incidents. Connecting it is one POST /me/connections with "type": "mcp", the name grafana, that URL and "auth": {"mode": "oauth"}, then the Grafana sign-in.
Metric names depend on how each service is instrumented, so the agent does not assume them. It lists the Prometheus data sources, then the metric names and the label that identifies a service (service, job or app), and picks the request counter and latency histogram it finds, such as http_server_request_duration_seconds from OpenTelemetry or http_requests_total from a Prometheus client. It writes down which metric and label it chose per service.
For each service it runs three range queries over the last 7 days and the 7 before: request rate (sum by (service) (rate(<requests>[5m]))), error rate (5xx responses over all responses) and p95 latency (histogram_quantile(0.95, sum by (le, service) (rate(<duration>_bucket[5m])))). It reduces each to a weekly figure and computes the change. Where a service has no histogram, it says p95 is not available rather than estimating it.
It then reads the week's alert history and Grafana incidents and matches them to services and to the largest changes, so a latency jump on Wednesday sits next to the incident declared that day. Read only: it silences, edits and creates nothing, and writes reliability.md in its sandbox.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the Grafana connection to find the Prometheus data source, the request counter and latency histogram each service exposes, and the label that names the service. For the last 7 days and the 7 before, query each service's request rate, error rate (5xx over all) and p95 latency. Read the week's fired alerts and incidents. Write reliability.md with a table of those numbers and their change per service, the three largest changes with the PromQL behind each and any incident or alert that lines up with them, a short incident list, and a note of the metric and label used per service. Read only: silence, edit or create nothing.",
"connections": [
"grafana"
]
}- 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
The session returns reliability.md as an artifact. It opens with one table, a row per service: requests, error rate and p95 for both weeks with the change. Then come the three largest changes, each with its PromQL in a code block and any matching alert or incident, then the week's incidents, then the note on which metrics were used.
Each query and its result is in the session's transcript, so an SRE can paste the PromQL into Explore and see the same series. Before the meeting, check the metric choices note: if a service exposes two request counters, the agent names the one it picked, and that is the line to correct in the prompt for next week.
Run it on every Monday before standup
An automation with a schedule trigger in a Project runs this weekly on a cron such as 0 8 * * 1 in your timezone. Once the metric names are settled, put them in the prompt so every week's report queries exactly the same series.
Set a webhook URL on the key and Rush POSTs run.completed with the session_url when the turn ends. Your server can read the session and post the service table to the channel the reliability review uses, with a link to the full report.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
Weekly reliability numbers usually come from screenshots of dashboards, which nobody can recompute and which hide how the number was made. The agent writes the PromQL, runs it through the connection in its own sandbox, and puts the query next to every number, so the review argues about the system rather than the chart.
Nothing in Grafana changes, and the full record of every query is kept with the session. One run per Grafana stack or per team can go at once, up to the key's concurrent run limit.
Frequently asked questions
Does it work with self-hosted Grafana?
The catalog entry is for Grafana Cloud. A self-hosted Grafana that runs Grafana's MCP server at a public address can be connected as a custom MCP server with POST /me/connections and named on the run the same way.
What if our services are not instrumented the same way?
The agent finds the counter and histogram for each service separately and notes which it used. Services with no latency histogram get no p95, and the report says so instead of inventing one.
Can it read Loki logs too?
Yes. The Grafana server queries Loki as well. Ask in the prompt for the top error messages per service, and the agent adds a LogQL query and its results to each section.
Why a 5-minute rate window in the queries?
It smooths single scrape gaps without hiding a short outage, and it is a common default for request metrics. If your scrape interval is long or your dashboards use another window, put that window in the prompt and every query uses it, so the report matches the charts people already know.