Skip to main content
The Requests page tells you what a request cost and which model served it. Request logs tell you what was actually said: the body Manifest sent to the provider, and the body that came back. The dashboard calls this feature Logs. It’s one toggle per harness.

​
What gets recorded

Recording happens per provider attempt, not per request. A request that falls back twice before succeeding produces three recordings, each with its own body pair, so you can see how the conversation was reshaped for each provider. An Autofix retry is its own attempt too, which is how you compare the request that failed against the patched one that worked. A request Manifest blocked itself, on a hard limit or a malformed body, has zero provider attempts and so no recording. There was no exchange to record.

​
Reading it back

Open a request in the dashboard’s Requests page and pick an attempt in the Attempts list. The initial call, each fallback, and an Autofix retry are separate attempts, and each one shows its own conversation. The Messages, Tools, and Raw tabs appear when that attempt has a recording. The Messages tab renders the exchange as a conversation, with a rail down the side listing every turn. Search the rail or filter it by role, and click any row to jump to that turn in the main pane. Assistant turns show the tool calls the model actually made, not the tool definitions your client offered it.

​
Turning it on

The switch is Enable logs, in the Logs section of each harness’s Settings page. New harnesses have it on. To make sure a harness records its logs, check Settings → Logs.
Recording stores your prompts and completions. Everything else Manifest keeps is metadata (Data and telemetry covers the distinction). If a harness handles data you’d rather Manifest never hold onto, leave recording off for that harness.

​
Retention

Recordings are deleted on a schedule. The metadata row in the request log stays; only the stored body pair goes away. Self-hosted installs can override this with REQUEST_RECORDING_RETENTION_DAYS. Setting it also overrides the per-plan split, so every recording on the instance expires on the same schedule.

​
Self-hosted storage

Logs were reintroduced in v6.18.0. On an older self-hosted install, upgrade Manifest first.
Recordings don’t live in Postgres. They’re gzipped and written to object storage, which you pick per instance.
The bundled compose file mounts a named volume manifest_request_recordings at /data/request-recordings and points Manifest at it. Nothing to configure when your compose file includes that volume; an install from before v6.18.0 needs one upgrade step first. The volume survives docker compose down the same way the Postgres volume does.
REQUEST_RECORDING_STORAGE defaults to auto, which picks the backend by what you’ve configured: any S3 setting present means S3, otherwise the mounted filesystem path. Set it to s3, filesystem, or disabled to decide explicitly.
Under auto, setting some S3 variables commits Manifest to S3. A bucket without a region, or one access-key half without the other, leaves recording with no working backend instead of falling back to local disk. Configure it fully or not at all.
Full variable list: Environment variables.

​
Platforms without a persistent disk

Railway, Render, Fly, Heroku, and Koyeb all give you an ephemeral filesystem, so local recordings there are wiped on every redeploy and every container restart. Point those deploys at S3-compatible storage, or accept that recordings only survive until the next deploy.