What the agent does
The Grafana Cloud notification arrives at a Rush webhook trigger and follows the prompt as untrusted data. The agent reads the alert rule through the Grafana connection, reruns its PromQL around startsAt, and searches Loki for the API's error lines in that window. A NestJS stack trace names the controller and the provider method, which is usually enough to tell an auth failure from a users failure before reading any code.
In an API like brocoders/nestjs-boilerplate (NestJS 11.1.18, TypeORM 0.3.28, Node 24.14.1 in .nvmrc), login is validateLogin in src/auth/auth.service.ts: it calls usersService.findByEmail, throws through invalidLoginException for a missing user, a social-only account or a wrong password, compares with bcrypt.compare, then creates a session through sessionService.create. Users live behind a ports-and-adapters layout, src/users/users.service.ts over src/users/infrastructure/persistence/relational/repositories/user.repository.ts and user.mapper.ts, with a parallel document adapter for MongoDB. A spike in 5xx on POST /api/v1/auth/email/login and a QueryFailedError in the logs send the agent to the repository and mapper, not the controller.
The repository has no unit tests yet: Jest's testRegex is .*\.spec\.ts$ with rootDir: src, and the existing suites are e2e specs in test/user/auth.e2e-spec.ts and test/admin/ that need the API and a database running through Docker Compose. So the agent adds a .spec.ts beside the failing provider, builds it with Test.createTestingModule and the real class under test, and reproduces the exception from the logs. Where the failure is in the query itself, it also starts PostgreSQL in the sandbox with the values from env-example-relational and runs the matching e2e spec.
It fixes the provider, repository or mapper, then runs npm test, npm run lint and npm run build so the change compiles under tsconfig.build.json and passes the ESLint config the project ships.
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 NestJS 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 error logs for the same window. Follow the stack trace to the cause in the auth and users modules, add a Jest test that reproduces it, fix it, and run npm test, npm run lint and npm run build. 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 with the rule's PromQL and the values that crossed its threshold, the LogQL query and the stack trace it returned, and a new .spec.ts that fails before the fix and passes after it. The diff is the spec and the fix in src/auth/ or src/users/; a change to an entity or migration is listed separately because it changes the schema.
A reviewer checks the spec reproduces the exception from the logs, that a fix in validateLogin still answers a wrong password and an unknown email the same way, so the endpoint does not reveal which accounts exist, and that the relational and document adapters stay consistent when one of them changed.
When the logs point at the database, a mail provider or an expired secret rather than code, the run explains that with the lines it found and opens no pull request.
Run it on every Grafana alert on the API
Set up an automation in the Project with this prompt and a webhook trigger. In Grafana Cloud, add a webhook contact point at the trigger's URL with the header Authorization: Bearer <secret>, and send this API's alert rules to it. Each notification becomes the event the agent reads under the prompt.
Disable resolved messages on the contact point and keep the policy's repeat interval longer than a run, since a delivery without an Idempotency-Key header always starts a fresh run. A login outage that trips several rules at once is easier to read as one grouped notification.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
The steps from a red login graph to a fix are mechanical but slow: rerun the query, find the trace in Loki, map the provider to its adapter, then stand up Postgres and the API to reproduce it. A Rush run does that in its own sandbox and keeps every query, test and build in the session, so a reviewer can follow the diagnosis line by line.
Auth incidents tend to come with neighbours, a users endpoint and a session refresh failing together. Each alert gets its own run in parallel on its own branch, nothing runs against production, and each ends in a pull request whose spec proves the fix or a report of what the data shows.
Frequently asked questions
My project has no unit tests. What does it add?
A .spec.ts beside the failing provider, which matches Jest's testRegex in package.json, so npm test picks it up with no config change. It tests the real class, not a mock of it.
Does it work with the MongoDB adapter too?
Yes. The boilerplate has relational and document persistence adapters for users; the agent fixes the one the logs implicate and checks the other has the same behaviour.
Does it run the e2e tests?
When the failure needs a database to reproduce, it starts one in the sandbox and runs the matching spec under test/ with npm run test:e2e. Otherwise the unit spec is the proof.
Can the alert payload tell the agent what to do?
No. Rush hands the payload to the agent as untrusted data under the automation's own prompt, so text inside an alert annotation cannot replace the instructions.