What the agent does
The agent clones the repository into its own cloud sandbox and reads the symptom you give it: event loop lag above 800 ms at peak, CPU around 60%, and every route slowing together. That pattern points away from a slow database (which would slow some routes, not all) and toward work that holds the single JavaScript thread: synchronous CPU work in a handler or middleware, a large JSON body built or parsed in one go, or blocking I/O. The agent looks for each of those in the code rather than guessing.
In an API like hagopj13/node-express-boilerplate it starts with src/app.js, because middleware there runs on every request. It notes the order: helmet(), express.json() with no limit, express.urlencoded, then xss() from xss-clean and mongoSanitize(), both of which walk every request body synchronously, then compression() and cors(). It reads ecosystem.config.json, which runs one pm2 instance ("instances": 1), so the whole pod's traffic shares one event loop, and src/config/logger.js, where winston writes each morgan access line to the console transport.
Then it reads the routes that do real work. src/models/user.model.js hashes passwords with bcryptjs, a pure JavaScript implementation, in the pre('save') hook at line 81 and compares them in isPasswordMatch at line 75; every login and registration spends CPU on the main thread there. src/models/plugins/paginate.plugin.js parses limit from the query string at line 35 with no upper bound, so GET /v1/users?limit=50000 loads that many documents, runs the toJSON plugin over each and serializes the whole array before the response leaves. src/services/token.service.js signs tokens with jsonwebtoken's synchronous jwt.sign, which is cheap per call but runs on every login and refresh.
Last, it reads the 30 most recent commits with git log -p, looking for a new middleware, a raised bcrypt cost, a dropped limit cap, a new dependency in package.json or a sync call (fs.readFileSync, crypto.pbkdf2Sync, zlib.*Sync) added to a request path. Where it can, it runs the suspect code in the sandbox with node --cpu-prof or a small loop under perf_hooks.monitorEventLoopDelay to show which one stalls the loop and by how much. It writes incident.md and changes no code.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Incident: Grafana shows the Node.js event loop lag on the API pods jumping above 800 ms during traffic peaks while CPU sits at 60%, and every route's latency rises together. Read the code, the configuration and the last 30 commits, find the most likely causes, and write incident.md with a timeline, each suspect with file and line evidence, and the check that would confirm or clear it. Change no code.",
"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, attached to the session as an artifact. It opens with a timeline of the commits in the window that touched middleware, models, services or dependencies, then ranks the suspects. Each suspect names its file and line, explains why it blocks the loop for every route rather than one, and gives the check that confirms or clears it: a CPU profile taken during a peak with --cpu-prof or the inspector, the eventloop_lag metric split by route if you export one, or a count of requests that hit /v1/users with a large limit in the access log.
Where the agent measured something in the sandbox, such as the time bcrypt.hash takes at the configured cost or the time to serialize a large page of users, the report shows the command it ran and the output, and says plainly that these numbers come from the sandbox, not from your pods. The session's transcript keeps every file it read and every command it ran.
Before acting, an engineer checks the top suspect against production: a profile from one pod during a peak settles most of these in minutes. The fixes are usually small (cap limit, move hashing to the native bcrypt package or a worker thread, run more than one process per pod), and a follow-up to the same session can ask the agent to make one as a pull request.
Run it on every event loop lag alert
A Grafana alert on nodejs_eventloop_lag_seconds (or whatever your Prometheus client exports) can call a webhook handler on your server that sends this request with the threshold, the time and the pods in the prompt. Each alert starts a fresh clone of the repository at the commit that is deployed, so the agent reads the code that is actually running.
With a webhook URL set on the API key, Rush POSTs run.completed when the turn finishes, and your handler posts the report's link next to the alert.
The use case this job follows, with its automation and trigger: Investigate an incident.
Why run it on Rush?
Finding event loop blocking by hand means reading every middleware, guessing which handler is synchronous, then trying to reproduce it locally with load. In a Rush sandbox the agent has the repository, Node and a shell, so it can read the code and time the suspect functions in the same place, without touching your machine or the running service.
The result is evidence, not an opinion: every suspect carries the file and line, and every number carries the command that produced it, kept in the session's transcript. If several services report lag at once, each alert can start its own run in parallel, up to the key's concurrent run limit.
Frequently asked questions
Can the agent profile my production pods?
No. It works on the repository in its own sandbox and does not reach your cluster. It can run and time code there, and the report tells you which profile or metric to capture in production to confirm each suspect.
Why would every route slow down when only one route is expensive?
Node runs JavaScript on one thread per process. A request that holds that thread for 800 ms delays every other request queued behind it, so latency rises on all routes together. The report points at the code that holds the thread, not just the route that looks slow.
Does it work with NestJS, Fastify or Koa instead of Express?
Yes. The investigation is the same: global middleware or hooks first, then the handlers that do CPU work, then recent changes. Name the framework in the prompt if the repository holds more than one service.
Will it change code or open a pull request?
Not with this prompt, which says to change no code. Once you have confirmed a cause, send a follow-up to the same session asking for the fix as a pull request.