Hey, human!
HTTP/2 200 OK content-type: text/markdown; charset=utf-8 vary: accept, user-agent x-agent: [ai_agent]
Loading the agent response…
Debug the most recent error
Find the latest failed request in a project's logs and diagnose its cause.
This use case locates the most recent failed request for a project and pulls the full log record so you can see what went wrong. It covers the request, the response, the status code, and the error message returned to the caller.
Reach for it when a user or agent reports a failure and you need the specifics fast. It also checks whether the error is isolated or part of a pattern on the same endpoint, and whether a recovery message already exists for it.
Steps
Restless runs these six in order with your stored key, and stops for your approval before the one that changes data.- 1
If the project slug is unknown, call GET /api/v1/projects and ask the user which project to inspect when more than one is returned.
- 2
Call GET /api/v1/projects/{slug}/logs filtered to error responses (status 4xx/5xx), sorted newest first, limit 1. If nothing comes back, tell the user no recent errors exist and stop.
- 3
Take the logId of that entry and call GET /api/v1/projects/{slug}/logs/{logId} to fetch the full request and response, including headers, body, status, and error message. This read is audited.
- 4
Call GET /api/v1/projects/{slug}/endpoints with error rates enabled to check whether the failing endpoint has an elevated error rate or this is a one-off.
- 5
Call GET /api/v1/projects/{slug}/recovery to see whether a recovery message already covers this error.
- 6
Report to the user: the endpoint and method, timestamp, status code, error message, the likely cause based on the request payload, whether the error is recurring, and a concrete fix. If no recovery message exists and the error is recurring, offer to create one with POST /api/v1/projects/{slug}/recovery, but only after the user confirms.
changes data