What the agent does
The agent reads the monitor through the Datadog connection, then the error logs and APM traces for the service in the 30 minutes around the alert. Datadog's Node tracer instruments Express under NestJS, so each trace names the route, such as POST /api/v1/auth/refresh, and the error span carries the exception. A rise in 401s on the refresh route reads very differently from a rise in 500s, and the agent counts both before it opens any code.
In a NestJS API like brocoders/nestjs-boilerplate, auth lives in src/auth/: auth.controller.ts maps the routes and auth.service.ts holds the logic, validateLogin, register, confirmEmail, forgotPassword, resetPassword, refreshToken, logout and more. refreshToken hashes a new random value, calls sessionService.updateByHash with the session id and the old hash, and throws UnauthorizedException if no session matched or the user has no role. Users live in src/users/, with users.service.ts over a repository that has both relational (TypeORM) and document implementations under infrastructure/persistence/. The agent checks which one the service runs before it trusts a stack trace.
It reproduces the failure in a Jest test. The project's jest config in package.json sets rootDir to src and runs files matching .spec.ts, so npm test picks up a new src/auth/auth.service.spec.ts built with Test.createTestingModule and the real service, with only the session and user repositories replaced. The end-to-end suites in test/user/auth.e2e-spec.ts need the API and a database running, through npm run test:e2e with env-cmd, and the agent runs them with the project's Docker Compose files when the fix touches a route's contract.
With the test failing for the right reason, it fixes the service, runs npm test and opens a pull request that quotes the log lines and trace, links the monitor, and says what the bug did to users: for example, logging them out early or letting a used refresh token succeed twice.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "A Datadog monitor on this NestJS service fired; its webhook payload follows this prompt. Use the Datadog connection to read the monitor and the error logs and APM traces from the 30 minutes around the alert, counting status codes per route. Find the code path that produced them in the auth and users modules, src/auth/auth.service.ts and src/users/, and check which persistence implementation is in use. Write a Jest regression test as a .spec.ts file under src/ using Test.createTestingModule, fix the code, run npm test, and run npm run test:e2e as well if the fix changes a route's behaviour. Open a pull request that quotes the log lines the fix addresses and links the monitor.\n\nMonitor payload:\n{payload}",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
],
"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
A pull request comes back with the fix in a NestJS provider, usually auth.service.ts or the session or users service it calls, and a new .spec.ts file that npm test now runs. The description quotes the logs and the route from the trace, links the monitor and lists the test commands with their summary lines. If the end-to-end suite ran, its result is in the description too.
The session's result, delivered in data.result on the run.completed webhook, explains the cause in a few sentences. The transcript records the Datadog queries, the Docker Compose setup if one ran and every Jest run, so a reviewer can see which tests passed on which database.
For an auth fix, the reviewer checks more than the green test: that a refresh token still works once and only once, that a deleted or role-less user is still refused, and that the fix changes no response shape a client depends on. Those are the cases the new spec should cover, and the review is the place to ask for one that is missing.
Run it on every Datadog monitor alert
Set up an automation with a webhook trigger in the Project for this API, with this prompt and a saved agent that names your Datadog connection. Datadog's Webhooks integration posts to the trigger URL with the trigger secret as the bearer token whenever a monitor message mentions @webhook-<name>, and the alert body follows the prompt.
If your platform team prefers its own relay, accept Datadog's webhook there and call POST /o/{org}/sessions with this request, the payload in input and the alert id as Idempotency-Key. A key allows max_concurrent runs at once, 4 by default, and answers 429 beyond that.
The use case this job follows, with its automation and trigger: Fix a bug from an alert.
Why run it on Rush?
Auth bugs are urgent and easy to fix wrongly. A Rush run takes the time a tired person would not: it reads the traces with your Datadog connection, clones the repository, builds the testing module, and runs Jest and, when needed, the end-to-end suite against a real database in its own sandbox. Every command and its output stay with the session.
Each alert gets a separate run and branch, so an auth monitor and a users monitor firing together do not block each other. The pull request carries the production evidence and the test, and the reviewer decides with the transcript in hand.
Frequently asked questions
My project has no unit tests yet. Is that a problem?
No. The agent adds the first .spec.ts file where Jest's rootDir and testRegex already look, so npm test runs it with no config change. The pull request says it added one.
Can it run the e2e tests that need Docker?
Yes, when the prompt allows it. The sandbox is a full computer, so the agent can bring up the project's Compose files for Postgres and run npm run test:e2e against them.
Will it touch real user sessions?
No. It reads logs and traces from Datadog, and works on a clone with test data. Production sessions change only when someone deploys the merged fix.
What if the monitor is about latency, not errors?
Change the prompt to read the slow traces instead of error logs. The agent then looks for the query or call that takes the time and proposes a fix with a test that pins the behaviour.