Diagnostic capture
Retain one request's content for a short window, so a specific failure can actually be investigated.
Atlas does not retain prompt or completion content. That is the right default, and it has one obvious cost: when a specific request goes wrong, there is nothing to look at.
Diagnostic capture is the exception. It is opt-in per request, flagged by you at the time you send it, and it does not change your organization's default in any way.
Flagging a request
Send the header:
x-atlas-diagnostic-capture: 1Accepted truthy values are 1, true, yes, and on (case-insensitive).
Anything else — including the header being absent — means no capture.
It is a header rather than a body field on purpose: a header survives request shapes the wire contract does not model, and never has to be stripped on the way to a backend that has never heard of it.
Record the request_id. A capture is addressed by request id and nothing
else. Without it, a capture exists but cannot be found.
The window
A capture is retained for at least 24 hours and never more than 25.
The slack is mechanical: expiry is a partition drop on an hourly boundary, not a
filtered query, so a capture ceases to exist rather than being hidden. The
database enforces the ceiling with a CHECK constraint on every row's own
window — not even a direct SQL writer, Atlas operator included, can store a
capture with a longer expiry.
Flag the request and report it the same day. There is no extension mechanism, and a capture that has aged out is gone rather than archived.
What is captured
The request body, the response content, and the request headers — minus every
credential-bearing header, which is removed before anything is written:
authorization, proxy-authorization, authentication, cookie,
set-cookie, api-key, and others. That stripping is enforced both in the
application and by a database constraint.
Reading one back
You cannot fetch a capture yourself. Send the request_id to your Atlas contact
and they will read it.
Two properties of that read are worth knowing:
- The gateway cannot read captures at all — not even its own. The service that writes them holds a database role with no read access to them.
- Every read is recorded in an append-only audit log with the reading identity, the time, and the request read — and the record is written whether or not a capture was found.
When to use it
Good uses
A reproducible bad output on a specific prompt. A structured-output violation you cannot explain. A request that failed in a way the error code does not account for.
Not this
Flagging all traffic as a substitute for your own logging. It is a per-request diagnostic tool, not a retention setting — and everything it captures disappears within about a day.
If your application needs a durable record of what it sent, log it on your side. See Data handling.