What the agent does
The agent investigates the supplied incident window and writes incident.md. In a FastAPI application like mealie-recipes/mealie, it first maps error fingerprints to the actual household controllers. mealie/routes/households/controller_mealplan.py:27 declares prefix="/households/mealplans"; mealie/routes/households/controller_shopping_lists.py:156 declares prefix="/households/shopping/lists". A shopping-list item failure and a meal-plan listing failure therefore get separate evidence trails. The prompt supplies the environment, UTC start and end, affected release and redacted Sentry events instead of asking the agent to guess which deployment broke.
Your incident handler reads the window through your authorized Sentry connection and appends its query text, event links, timestamps, stack traces and release identifiers to input. The example request names only a harness and a repository; writing 'use Sentry' in that prompt grants no account access. If the evidence bundle is missing, the agent records the missing source rather than inventing telemetry. Repository access comes from the Rush GitHub App installation on your own application, not from the public example used to explain these paths.
The agent compares the affected revision with recent commits using git log --since='7 days ago' -- mealie/routes/households/controller_mealplan.py mealie/routes/households/controller_shopping_lists.py and reads candidate changes with git show. It checks date-filter construction against the failure shape: controller_mealplan.py:99 calls QueryFilterBuilder.combine_filters(q.query_filter, date_filter). It also follows shopping-list operations into their service calls; controller_shopping_lists.py:258 calls self.service.add_recipe_ingredients_to_list(item_id, data). Temporal proximity alone never establishes causation, so each candidate must explain the observed request and traceback.
The report distinguishes observed events, source-code facts and hypotheses. It can use tests/integration_tests/user_household_tests/test_group_mealplan.py as behavioral context; lines 21–24 construct requests with start_date and end_date. It records relevant environment differences before suggesting a local reproduction. pyproject.toml:7 requires Python >=3.14,<3.15 and line 17 pins fastapi==0.143.0, so an unrelated interpreter error does not become an incident explanation. The investigation changes no application files, creates no fix branch and makes no production requests that mutate meals or shopping lists.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Investigate the FastAPI incident described in the evidence bundle appended below. The caller must supply the UTC incident window, environment, release identifier, redacted Sentry errors and stack traces, event URLs, and the exact queries run through its Sentry connection. If these are absent, report what is missing without inventing events. Compare the supplied evidence with commits from the last 7 days affecting the meal-plan and shopping-list controllers, then follow implicated services. Write incident.md with a UTC timeline, ranked likely causes, evidence and counterevidence for every claim, source file and line references, query provenance, and unresolved questions. Change no application code, push no commits, and perform no production writes.",
"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
The deliverable is incident.md, organized into scope, timeline, affected routes, candidate commits, likely cause, contradictory evidence and next checks. Each timeline entry points to a supplied Sentry event or deployment record. Each code explanation cites the revision and file location it relies on. When logs, metrics or release metadata are unavailable, the report states that limit explicitly. A plausible date-filter regression stays a hypothesis until the evidence connects it to the failing endpoint.
The on-call reviewer checks that the incident and comparison windows use the same timezone, that the inspected commit is actually deployed, and that the proposed mechanism explains more than one isolated traceback. Read the session result for the summary and its artifacts for the report file. Rush's developer quickstart, under 'Watch, control, read', documents both the session read and artifact download. This page describes the requested output; it does not assert that a Mealie incident occurred or that a particular fix has been proved.
Run it on every Sentry incident window
Connect your Sentry alert webhook to your own handler. The handler validates the alert, groups repeated notifications for the same incident, fetches the approved evidence through its Sentry connection and sends one POST /o/{org}/sessions request with that bundle appended to input. Keep customer payloads, authorization headers and unrelated household data out of the export. A follow-up investigation should name what changed in the evidence, so repeated alerts do not produce indistinguishable reports.
Read the completed session or configure a completion webhook on the API key to collect the report. Keep notification delivery separate from the investigation itself: this task never changes alert rules, resolves the Sentry issue or rolls back a deployment. Those consequential actions need their own explicit request after a person has assessed the findings.
The use case this job follows, with its automation and trigger: Investigate an incident.
Why run it on Rush?
Incident investigation often starts while the on-call engineer is already handling mitigation. Rush gives the repository analysis its own cloud sandbox, so reading commit history and preparing an evidence table do not compete with an emergency change in the engineer's local working tree. The output stays focused on household controllers, release context and uncertainty instead of becoming a generic explanation of FastAPI exceptions.
Several incident bundles can be investigated independently within the key's concurrency limit. The session transcript retains the commands and their output, letting a reviewer inspect which revisions the agent compared. That matters when a suspicious shopping-list commit turns out not to be deployed. The useful proof is a traceable argument with missing evidence called out, not an unsupported declaration that the incident is solved.
Frequently asked questions
Does this request give the agent direct Sentry access?
No. The body shown contains no connections field, and a prompt cannot grant account access. Your handler supplies evidence obtained through its own authorized Sentry connection; a separately configured tool connection requires an explicit grant.
Will it patch the meal-plan or shopping-list code?
The requested task is read-only application analysis. It writes incident.md and identifies what a follow-up reproduction should test. Ask for a separate fix only after reviewing the incident evidence.
What if the error started after a commit but has another cause?
The report must include counterevidence and alternative explanations, including deployment or configuration changes. A timestamp match is a lead to investigate. It is insufficient proof that the code change caused the spike.
Must the application be Mealie?
Mealie supplies concrete examples of the route and test structure. Replace the repository resource with your own installed application and describe its affected endpoints. The agent reads that checkout rather than assuming your files match this example.