Diagnostics

Start diagnostics with the visible symptom and relevant Server state. Do not collect a debug bundle unless ordinary checks are insufficient and you can review the resulting data safely.

Check startup and readiness

For Server, review the process console and its data-root logs. /healthz indicates that the health endpoint responds; /readyz checks database/bootstrap readiness. Neither proves that setup is complete, a provider is connected, or a model can answer a request.

The --log-level option accepts error, warn, info, debug, or trace. Prefer the least detailed level that can answer the question; detailed logs may reveal operational context.

Recover a Server administrator

If the sole Server administrator is unavailable, stop the running instance first. Run the recover-admin subcommand against the same data root and configuration, following the interactive prompt. It replaces the sole administrator credentials and revokes all sessions; do not put a password in command-line arguments.

Handle debug data as sensitive

Debug capture can include URLs, headers, request/response bodies, prompts, attachments, or credentials beyond the permanently redacted HTTP Authorization value. An exported bundle may have gaps. Inspect and minimize it in a trusted environment before sharing; never post an unreviewed bundle publicly.

If evidence is still insufficient

Record the Server release, deployment mode, database backend, and the exact visible error. Remove setup tokens, API keys, provider credentials, private URLs, and unnecessary user content. If the problem persists, use the project's approved private support channel with the smallest sanitized evidence set.

Next steps

For model and client failures start at Troubleshooting . For request-stage evidence see Request history .