Trace an Ollama 500 to the failing stage.

Capture before changing anything

Record the app/runtime version, OS, exact endpoint, model name and digest, request options, failure timestamp and HTTP response. Keep a private original if needed; share only a minimal sanitized excerpt. A message mentioning a remote host needs its own endpoint investigation. Do not assume it came from a local model process.

Separate transport from generation

First check the local model-list endpoint on the intended instance. Connection refused is a reachability or process issue, not an HTTP 500. A reachable list endpoint followed by a generation failure narrows the investigation but does not prove the cause. Preserve the generation error body before using a command option that suppresses it.

curl -i http://127.0.0.1:11434/api/tags
ollama --version
ollama list

Find the right log

For a manual server, read the terminal that launched it. The official troubleshooting page lists macOS, Windows and Linux service log locations. On Linux a bounded service excerpt is often enough to identify the failing phase. On Windows open the Ollama log folder through the platform instructions. Inspect logs locally and remove prompts, paths and account details before sharing.

# Linux systemd test service only
journalctl -u ollama --since '10 minutes ago' --no-pager

Follow the failure stage

Load/allocation failure: confirm model identity, free memory and context before a smaller, separately recorded attempt. Device initialization failure: inspect the actual backend and driver combination; do not reset a shared GPU. Failure only at longer inputs: save token length and context settings. Remote endpoint failure: check routing and local/cloud model selection. These are diagnostic branches, not reproduced fixes.

Use a controlled retest

After one authorized change, repeat the original request with the same model digest and parameters. A later success with a different model proves only that different condition. If reducing context allows a short request to finish, preserve the original failure rather than announcing a universal repair. Record success, failure or not-run for every attempted branch.

Avoid destructive shortcuts

Do not clear the model store, reinstall drivers, restart a shared machine or modify a container daemon merely because an error page lists those possibilities. First establish the failing component and preserve a rollback path. If more evidence is needed, package the version, digest, minimal public prompt, options, sanitized error and one relevant log excerpt for a maintainer.

Rollback and close the incident

Restore the previous configuration and stop only the temporary process you started. Confirm that the prior working path still works. The downloadable incident template includes before/after conditions and unresolved questions. The interactive tool below never reads local logs, contacts a model server or changes your machine.

Use failures as evidence about a configuration

The two-Spark source reports that a Qwen FP8-KV configuration could answer short inputs but failed on the first chunked input, while separate GLM attention backends failed before a forward pass. These are examples of different failure stages, not fixes for every HTTP 500. A useful incident record preserves the exact model, engine, input shape and error before changing one setting.

Sources & change log

1. Ollama troubleshooting ↗Checked 2026-10-17 · Log locations and diagnostic entry points; no universal 500-error fix.
2. Ollama list models API ↗Checked 2026-10-17 · Installed-model digest capture.
3. Ollama generate API ↗Checked 2026-10-17 · Local request fields and response shape.

17 Oct 2026 · Revision 2. Source-based task guide and downloadable resource. Source documentation inspected; environment reproduction not run. Moving documentation may change after review.