MonitoringAll sections
Monitoring
Monitoring shows how your backend is behaving: how many requests it serves, how fast it answers and how often it fails. It breaks the numbers down by endpoint and keeps a searchable log of every request.
In the console: Operate › MonitoringUpdated October 12, 2026
Why you need it
When a user says the app is slow or broken, you need to know whether the backend agrees: which endpoint, since when, and with what error. Without monitoring that means guessing, or adding logging after the fact and waiting for it to happen again. Monitoring records it from the first request, so the evidence is already there when you need it.
For example
- A user reports a failed checkout. You filter the log to that endpoint and find the error.
- After a change, you check that nothing got slower.
- You look at which endpoints get the most traffic before deciding what to optimise.
- Your agent reads recent errors over MCP and works on the endpoint that is failing.
How it works
Every request is recorded
The runtime logs each API request it serves: method, path, status, latency and time.
The numbers come from that log
Average latency, request count, success rate (no 4xx or 5xx) and reliability (no 5xx), over the time range you pick.
Each endpoint gets its own view
Traffic, p95 latency and error rate per endpoint, so a slow or failing route stands out.
Unusual behaviour is flagged
Anomalies and system events appear beside the charts. Problems that need a decision go to Autonomy.
Try it
Once your coding agent is connected, ask it:
Is anything in my backend failing right now? Show me the errors grouped by endpoint.Good to know
- Monitoring shows what happened. Deciding what to do about it happens in Autonomy, so the two never give different answers about the same problem.
- A new project shows nothing until something calls its API.