What the agent does
The agent starts from the window named after the prompt and the Datadog connection. It searches logs for the Api and Identity services in that window, grouped by status code, route and exception type, reads request rate and latency for the same routes, and lists the monitors that triggered. It also reads the window on either side, because a 5xx spike that begins two minutes after a deploy and ends with a rollback tells a different story than one that climbs with traffic.
Then it opens the clone. In a solution like bitwarden/server, bitwarden-server.slnx holds many projects, global.json pins the SDK to 10.0.103 and Directory.Build.props targets net10.0 with TreatWarningsAsErrors on. Both web hosts, src/Api/Program.cs and src/Identity/Program.cs, build with Host.CreateDefaultBuilder, UseBitwardenSdk() and AddSerilogFileLogging(), so the log lines in Datadog carry Serilog's source context, and a context such as Bit.Identity.IdentityServer.RequestValidators.ResourceOwnerPasswordValidator points at one file. A 400, 404 or 409 that passed through ExceptionHandlerEndpointFilter in src/Libraries/ExceptionHandling was a BadRequestException, NotFoundException or ConflictException the code meant to return; a 500 is the real signal.
With the failing routes known, the agent runs git log --since=7.days over src/Identity, src/Api/Vault, src/Core/Vault, src/Core/Auth and src/SharedWeb, and reads the diff of every commit that touches the file a log context names. On the identity side that is src/Identity/Controllers/AccountsController.cs, InfoController.cs and SsoController.cs, and the validators under src/Identity/IdentityServer/RequestValidators: BaseRequestValidator.cs, ResourceOwnerPasswordValidator.cs, CustomTokenRequestValidator.cs, DeviceValidator.cs, TwoFactorAuthenticationValidator.cs and WebAuthnGrantValidator.cs. On the vault side it is CiphersController.cs, FoldersController.cs, SyncController.cs and SecurityTaskController.cs under src/Api/Vault/Controllers, and CipherService.cs and CipherSyncPushService.cs under src/Core/Vault/Services/Implementations.
To check a hypothesis it may run the tests that already cover the suspect, for example dotnet test test/Api.Test for CiphersControllerTests.cs, FoldersControllerTests.cs and SyncControllerTests.cs, or dotnet test test/Identity.IntegrationTest for the Login, Grants and RequestValidation folders, with the SDK global.json names. It changes no code and nothing in Datadog. Each statement in the report is tied to a query, a commit hash or a command, so the on-call engineer can rerun any of them.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Error rates for the ASP.NET Core Api and Identity services rose between 14:05 and 14:40 UTC today. Use the Datadog connection to read that window: error logs grouped by status code, route and exception type, request rate and latency for the /accounts, /connect/token, /ciphers, /folders and /sync routes, and any monitors that triggered. Open the repository and compare the window with the commits of the last 7 days to src/Identity, src/Api/Vault, src/Core/Vault, src/Core/Auth and src/SharedWeb; read the diff of every commit that touches a controller, request validator or service the log contexts name. You may run dotnet test on the test project that covers a suspect file to check a hypothesis, using the SDK in global.json. Write incident.md with a summary, a UTC timeline, the most likely cause with commit and file, the evidence for each claim (the query or command and its result), the causes you ruled out and every query you ran. Change no code and change nothing in Datadog.",
"connections": [
"datadog"
],
"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 incident.md, listed on the session's artifacts with a download link, plus the transcript of every Datadog query and shell command behind it. The summary names the service, the routes and the status codes: for example 500s on POST /connect/token from the Identity host while /ciphers and /sync on the Api host stayed healthy. The timeline puts the deploy, the first failing log line, each monitor trigger and the recovery in UTC order.
The cause section names a commit and a file, such as a change to DeviceValidator.cs or TwoFactorAuthenticationValidator.cs, and quotes the lines that explain the exception type in the logs. Below it the agent lists the causes it ruled out, with the query or test result that ruled each one out, and a final section with every Datadog query it ran so the reader can paste them into the Logs Explorer.
Before acting on the report, the on-call engineer checks that the quoted log contexts match the frames in their own Datadog view, that the commit the report blames was deployed before the first failing line, and that the suggested next step, a revert or a targeted fix, is small enough to ship under incident conditions. The report proposes no diff; it ends where the engineer's decision begins.
Run it on every Datadog monitor alert
Create a Datadog webhook integration that posts the monitor's payload to a handler on your server; the handler sends this request to POST /o/{org}/sessions with the alert's JSON, its window and the service name appended after the prompt, and the monitor's alert id as the Idempotency-Key, so Datadog's retries return the run already started rather than a second one. Alternatively the handler forwards the payload to a webhook trigger on an automation in the Project with this prompt, sending the trigger's secret as Authorization: Bearer, which Datadog itself cannot send.
A monitor that flaps fires repeatedly, so set the automation's max_runs_per_hour low; extra fires come back as skipped with rate_limited instead of starting duplicate investigations. With a webhook URL on the API key, Rush POSTs run.completed with the session_url when the report is written, and your incident channel can link to it.
The use case this job follows, with its automation and trigger: Investigate an incident.
Why run it on Rush?
A large .NET solution is slow to investigate on a laptop under pressure: restoring packages, building with warnings as errors and running one integration project each take minutes, and the engineer is doing it while also talking in the incident channel. On Rush the agent does that work in its own sandbox with the pinned SDK, while the engineer reads Datadog directly. Several hypotheses can run as several sessions at once, each with its own clone.
The result is a report with proof. Every claim points at a query the reader can rerun or a commit they can open, and the transcript shows which dotnet test commands ran and what they printed. When the report is wrong, the reader can see exactly where the reasoning left the evidence, which is more useful during an incident than a confident paragraph with no sources.
Frequently asked questions
Does the agent need write access to Datadog?
No. The Datadog connection is used to search logs, metrics, monitors and incidents, and the prompt tells the agent to change nothing there. The report lists every query so a reader with their own Datadog login can rerun each one.
Which log fields does it rely on?
The Serilog source context, the HTTP route and status code, and the exception type. In bitwarden/server both hosts log through AddSerilogFileLogging(), so the source context names the controller, validator or service class, which maps directly to a file under src/Identity, src/Api or src/Core.
Will it run the whole test suite?
No. The CI workflow runs dotnet test ./test across every project, which is far too slow for an incident. The agent runs the single test project that covers the suspect file, such as test/Api.Test or test/Identity.IntegrationTest, and only to confirm or rule out a hypothesis.
Can it propose the fix as well?
Not in this run; the prompt says to change no code so the report stays an investigation. Once the on-call engineer agrees with the cause, a second session can take incident.md as input and open a pull request with a test and a fix.
What if the window has no clear signal?
The report says so. It lists the queries that came back flat, the commits it read that touched nothing on the failing routes, and what it would look at next, for example the database or the Azure queue behind src/Events. A report that admits uncertainty is still a useful first pass.