# Fix an Express API Bug From a Datadog Monitor Alert

Yes. A Datadog monitor starts a run; the agent reads the error logs and traces, fixes the Express route with a Jest test and opens a pull request that quotes them.

[Run this on Rush](https://cloud.getrush.ai/run/fix-datadog-alerts/express/), in a Project that has your repository.

## What the agent does

The run begins with the monitor's webhook payload and the Datadog connection. The agent reads the monitor to learn what it measures, an error rate on a route or a count of 5xx responses, then pulls the error logs and the APM traces for the service from the 30 minutes around the alert. Traces from `dd-trace` name the Express route as the resource, such as `GET /api/articles` or `PUT /api/articles/:slug`, and that is how the agent narrows a burst of errors to one handler.

In an Express API like `gothinkster/node-express-realworld-example-app`, those routes live in `src/app/routes/article/article.controller.ts`, and each handler calls a function in `article.service.ts` that talks to Prisma: `getArticles`, `getFeed`, `updateArticle`, `addComment` and the rest. The agent reads the handler and the service function together, and also the error middleware in `src/main.ts`, which turns an `HttpException` into its `errorCode` and sends any other error as a 500 with its message. A 500 in the logs therefore means an exception the service did not wrap, which narrows the search further.

It reproduces the failure in a Jest test before it changes anything. The repository's tests live in `src/tests/services/`, run through Nx with `npm test`, and replace Prisma with a deep mock from `jest-mock-extended` set up in `src/tests/prisma-mock.ts`. The agent follows that pattern: it makes the mocked `prisma.article` call return what production must have returned, such as `null` for a deleted article, and asserts the service throws the right `HttpException` instead of crashing. Then it fixes the service, runs `npm test` and checks that the new test fails without the change.

It opens a pull request that quotes the log lines and the trace resource the fix addresses, links the monitor, and states the cause in plain terms. When the data points outside the code, a database outage or a client sending a malformed body, it opens no pull request and says what it found.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "claude",
  "input": "A Datadog monitor on this Express 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. Use the traces' route resource to find the handler in src/app/routes/article/article.controller.ts and the service function in article.service.ts that produced them, and check how the error middleware in src/main.ts reported it. Write a Jest regression test in src/tests/services/ using the Prisma mock in src/tests/prisma-mock.ts, fix the code, run npm test, and open a pull request that quotes the log lines the fix addresses and links the monitor. If the cause is not in the code, open no pull request and say what you found.\n\nMonitor payload:\n{payload}",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ],
  "connections": [
    "datadog"
  ]
}
```

1. **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.
2. **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.
3. **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 on your repository with a small diff in the route's service, often a missing `null` check or an unwrapped Prisma error turned into an `HttpException`, and a new case in `src/tests/services/article.service.test.ts`. The description carries the quoted Datadog log lines, the route resource from the trace, the monitor link and the `npm test` output summary. Your CI runs on it like any other pull request.

The session's `result`, delivered as `data.result` on the `run.completed` webhook when the key has one, sums up the alert, the cause and the change. The transcript at `GET /o/{org}/sessions/{id}/messages` holds each Datadog query and its answer and each test run, so the reasoning from log line to fix can be followed step by step.

A reviewer checks that the test fails on the old code, that the status code the fix returns is the one API clients expect (a 404 for a missing article, a 422 for a bad body), and that the fix does not hide a database problem behind a client error.

## Run it on every Datadog monitor alert

Create an automation with a webhook trigger in the Project for this API, with this prompt and a saved agent that names the Datadog connection. Datadog's Webhooks integration then posts each alert to the trigger's URL with the trigger's secret as a bearer token, once the monitor message mentions `@webhook-<name>`. The alert body arrives after the prompt as event text.

To start runs from your own code instead, take Datadog's webhook on your server and send `POST /o/{org}/sessions` with this request, the payload appended to `input` and the alert id as the `Idempotency-Key`. A key runs at most `max_concurrent` sessions at once, 4 by default, and answers `429` past that, so an alert storm queues rather than fans out without limit.

## Why run it on Rush?

Fixing an Express bug from an alert needs three things at once: Datadog open to the right time window, the repository checked out at the deployed commit, and Node with the dependencies installed to run Jest. A Rush run assembles all three in its own sandbox each time, queries Datadog through your connection, and keeps every command and its output on the session.

The result is proof, not a summary. The pull request quotes the production logs, the test shows the failure and the fix, and the transcript shows the run did what it says. When several monitors fire, each gets its own run with its own clone, and none of them waits for a person to be awake.

## Frequently asked questions

### Does my Express app need dd-trace?

For traces, yes: APM traces are what name the failing route. With logs alone the agent still works from stack traces and messages, but it has to search the code for the line instead of reading the route from the trace.

### Will it test against a real database?

It follows the tests the repository already has. Here they mock Prisma, so the regression test does too. If your project has integration tests against Postgres, say so in the prompt and the agent runs them in its sandbox.

### Can it deploy the fix?

No. It opens a pull request, and your normal review, CI and deploy apply. Nothing reaches production until a person merges it.

### What does it send to Datadog?

Read queries only, as the prompt asks: the monitor, logs and traces. The transcript lists each call with its arguments, so you can confirm nothing was muted or edited.