For AI agents: the complete documentation index for the Restless API is available at https://build.restless.ai/llms.txt. This page is also available as Markdown at https://build.restless.ai/usecases/triage-a-spike-in-failed-requests.md (or send an Accept: text/markdown request header).

Triage a spike in failed requests

Find what is behind a jump in errors and read the request that proves it.

When error volume jumps, the hard part is not noticing it, it is finding the one request that explains it. This walks from the shape of the spike down to a single failing exchange you can read end to end.

Reach for this when someone reports that things started breaking and you need to say what broke, where, and for whom, rather than just confirming that something did.

A curated task for the Restless API: the calls to make, in order, as the API's owner wrote them. Humans run this as a guided conversation at the same URL; the steps below are that same recipe.

Steps

1. Confirm the identity and access behind the API key with `GET /api/v1/me`.
2. Pick the target project. If you only have an example slug, verify it with `GET /api/v1/projects/{slug}`, or browse options via `GET /api/v1/projects`.
3. Establish the shape of the spike with `GET /api/v1/projects/{slug}/metrics`, passing `groupBy=status` plus `since` and `until` to bracket the window the user is asking about.
4. Find where the errors are concentrated with `GET /api/v1/projects/{slug}/endpoints`, passing `withErrors=true` over the same window. This ranks endpoints by volume and reports their error rates.
5. Pull the failing requests themselves with `GET /api/v1/projects/{slug}/logs`, filtering on `status` and, once step 4 names an endpoint, `urlContains`.
6. Open one representative failure with `GET /api/v1/projects/{slug}/logs/{logId}` for the full request and response, then explain the failure from that record rather than from the aggregate.