What the agent does
A Grafana Cloud alert posts to a Rush webhook trigger, and its notification follows the prompt as untrusted data. The agent opens the rule through the Grafana connection, reruns its PromQL around startsAt, and searches Loki for the service's lines in that window. An Axum service with TraceLayer logs each request's method, URI, status and latency, so the agent can split the errors by route before reading a handler.
In a service like launchbadge/realworld-axum-sqlx (Axum 0.3, SQLx 0.5 on PostgreSQL, edition 2021), the article routes are in src/http/articles/mod.rs, with listing and the feed in listing.rs and comments in comments.rs. get_article runs one sqlx::query_as! that joins article and "user", counts article_favorite rows and checks follow, then maps a missing row to Error::NotFound. src/http/error.rs turns Error::Sqlx and Error::Anyhow into a 500 and logs the real error, so a Loki line with a SQLx message points at a query, while a run of 422s points at the UnprocessableEntity validation in create_article or update_article.
SQLx checks its query! macros against a live database at compile time, so the sandbox needs PostgreSQL before anything builds. The agent follows .github/workflows/rust.yml: it sets DATABASE_URL and HMAC_KEY, installs sqlx-cli with the postgres feature, and runs sqlx db setup to apply migrations/1_setup.sql to 4_article.sql. The crate has one unit test, test_slugify, and the README leans on the RealWorld Postman collection for coverage, so the agent adds a #[tokio::test] against the database that sends the request from the logs, or a plain #[test] when the fault is in a pure function like slugify.
Then it fixes the handler or the SQL, runs cargo build and cargo test, and keeps cargo fmt and cargo clippy clean, since a query change also has to compile against the migrated schema.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "A Grafana alert fired for this Rust service; its payload follows this prompt. Use the Grafana connection to read the alert rule, run its Prometheus query around the firing time, and query the Loki logs for the same window. Find the cause in the article handlers, set up the database the way the CI workflow does, add a cargo test that reproduces it, fix it, and run cargo test. Open a pull request that includes the PromQL and LogQL queries, the log lines behind the diagnosis, and the test output before and after the fix. If the evidence does not point at code, say what it points at instead.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- 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 a pull request whose description quotes the rule's PromQL with the route and values that tripped it, the LogQL query with the request and error lines it returned, and the new test failing and then passing under cargo test. The diff is the test and the change in src/http/articles/; a new migration is listed apart from the handler change.
A reviewer checks that the test hits the same route and input as the logs, that a SQL change keeps the "favorited!" and "favorites_count!" non-null overrides true, and that a 500 is fixed at its cause rather than turned into a 404 by mapping every error to Error::NotFound. The repository's CI then runs the build, the tests and the Postman suite on the pull request.
When the queries show the database pool exhausted, a slow host or a deploy in progress, the run reports that with what it found and leaves the code alone.
Run it on every Grafana alert on the service
Add an automation to the Project with this prompt and a webhook trigger; Rush shows the URL and secret once. In Grafana Cloud, make a webhook contact point at that URL with Authorization: Bearer <secret>, and route the service's alert rules to it. The notification body becomes the event under the prompt.
Skip resolved notifications and set a repeat interval longer than a run, because each delivery without an Idempotency-Key header is a separate run. The automation's runs-per-hour limit caps a rule that flaps.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
A Rust service with compile-time checked SQL cannot even be built to reproduce a bug without a migrated database, which makes the first hour of an alert slow: the query, the logs, Postgres, sqlx db setup, a cold cargo build. A Rush run does all of it in its own sandbox and keeps each command's output, so the evidence travels with the fix.
When one bad query breaks several article routes at once, each alert gets its own run in parallel on its own branch, production is only read through Grafana, and each run ends in a pull request whose test proves the fix or a clear account of what the data points to.
Frequently asked questions
SQLx needs a database to compile. How does the sandbox build?
It starts PostgreSQL, sets DATABASE_URL, and runs sqlx db setup from sqlx-cli, the same steps the repository's rust.yml workflow takes, so the query! macros check against the migrated schema.
The crate barely has tests. What does the agent add?
A test that reproduces the failure from the logs: a #[tokio::test] against the sandbox database for a handler or query, or a plain #[test] for a pure function such as slugify, which already has one.
Does it work without Prometheus metrics in my service?
The alert rule has to query something, and the agent reruns that query as written. If the service only emits logs, a Loki-based rule works too, since the agent reads the rule before querying.
Will it touch the running service?
No. It reads metrics and logs through the Grafana connection and changes only the repository, through a pull request you merge and deploy as usual.