Duty Desk Note: Fields for a Failed AI Request

A failed AI request needs a record that another engineer can understand without repeating your investigation. “The model failed” is not enough: the request might have stopped inside your application, at a relay, or after reaching an upstream provider. Record what you observed, distinguish it from what you suspect, and leave unknown fields explicitly unknown.

The fields below form a practical incident template. They are fields for your own log or ticket, not a claim that every API returns them.

The timestamp and impact establish the incident

Record when the failure happened. Use a timestamp with a timezone, preferably UTC. Keep the request start time and failure time if both are available. These let someone match your report against service logs without guessing which local clock you used.

Describe the user-visible impact. Write what actually happened: a chat response never appeared, a coding task stopped, or a background job missed its output. State the observed scope, such as one request or several affected jobs. Do not turn a single failed request into a claim of a wider outage.

Request identifiers connect the evidence

Save your application's request ID. This is the identifier your system assigns to the operation. Also save any relay or upstream request identifiers returned in headers or error details, keeping their original field names and sources. They may identify different parts of the request path.

If an identifier was not returned, say so. A missing upstream ID does not prove the upstream provider never received the request; it only limits what you can correlate.

The destination and model show the intended route

Record the client, destination, and requested model. Include the SDK or CLI name and version, the configured API base, the endpoint path, and the exact model identifier sent. A display name such as Gemini 2.5 Flash can help readers, but it should not replace the actual value submitted by your application.

For Relay365, the API base is https://api.api365relay.com, and OpenAI clients add /v1. Keeping the base and endpoint separate in your record makes duplicated or missing path segments easier to spot. Avoid recording URLs that contain secrets.

Status and error text describe the observed failure

Capture the HTTP status if a response arrived. A client-side timeout or connection failure may have no HTTP status at all. Record the error code and a sanitized error message separately; they often carry more detail than the status alone.

• A 401 response suggests checking authentication, but the error details are still needed to identify which credential or service rejected the request.
• A 429 response indicates a rate or quota constraint at the responding service; preserve any retry guidance it supplies.
• A 5xx response indicates a server-side failure somewhere in the responding path, not automatic proof that the model provider caused it.

Timing and attempts explain the request lifecycle

Record elapsed time, timeout settings, and each attempt. Separate the user's logical operation from individual network attempts. One user action may produce several requests if the SDK retries automatically.

For streaming, note whether headers arrived, whether any output appeared, and whether the stream ended normally. A stream can begin successfully and fail later. Before retrying a request that triggers external actions, check whether those actions already happened.

Usage and evidence need explicit limits

Save reported usage without guessing missing values. If the response contains token usage, preserve it. If usage is absent, write “not reported,” not zero. A failed client response does not by itself establish whether processing occurred or whether a charge applies.

Keep only the evidence needed for investigation. Remove API keys, authorization headers, personal information, and confidential prompt content. Input size, message count, and enabled features may be enough to reproduce the problem without retaining the original conversation.

The handoff names the next check

Close with the current hypothesis, supporting evidence, owner, and next action. Relay365 fits teams wanting pay-as-you-go access to many model families through a relay, including use with Claude Code, Codex, Gemini CLI, and OpenAI SDKs. If that matches your workflow, create a Relay365 account and make this incident record part of your integration checklist.