# Error/debug logs in spaces

**URL:** <https://discuss.huggingface.co/t/error-debug-logs-in-spaces/172682>\
**Category:** Spaces\
**Created:** [January 21, 2026, 5:21pm UTC](https://discuss.huggingface.co/t/error-debug-logs-in-spaces/172682 "2026-01-21T17:21:53Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\
**Post date:** [January 22, 2026, 8:37am UTC](https://discuss.huggingface.co/t/error-debug-logs-in-spaces/172682/2 "2026-01-22T08:37:01Z")

</div>

You might be able to capture logs that flow by unseen through environment variable settings.

Also, in a Zero GPU environment, the number of processes running simultaneously increases, so for debug logging, using `logging` instead of standard output like `print` is more reliable. I often resort to `print` as a quick fix myself, but…

* * *

For your Space, the best ways to “display logs” are a mix of (A) using the built-in Logs UI correctly, (B) making your app’s stdout/stderr reliably visible (buffering is the usual culprit), and (C) streaming logs to your own terminal so you keep them even when the runtime changes.

You are **“Running on Zero”** (ZeroGPU). That increases the odds you’ll see restarts and short-lived execution contexts under load. It also makes “I clicked Logs and the error is gone” more common. ([Hugging Face](https://huggingface.co/spaces/alexnasa/ltx-2-TURBO "LTX-2 Video [Turbo] - a Hugging Face Space by alexnasa"))

* * *

## 1) Use the built-in Logs UI the right way (fastest check)

Hugging Face’s own Spaces docs describe debugging via **Build logs** and **Container logs** in the “Open Logs” modal. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-sdks-docker-first-demo "Your First Docker Space: Text Generation with T5"))

- **Build logs** : dependency install, image/build steps, scheduling.
- **Container logs** : what your running app prints to stdout/stderr.

This UI is essentially “current build stream + current container stdout/stderr.” It is not a multi-replica log explorer. So if the runtime restarts, your “current container logs” view can look like the logs “disappeared.” (That’s a platform model issue, not your code.)

Also note: there are known cases where the logs UI fails (“Failed to load logs: Not Found”) even when it claims logs should exist. ([Hugging Face Forums](https://discuss.huggingface.co/t/space-wont-start-logs-not-found/54149 "Space won't start - logs not found"))  
When you hit that, you need option #3 below.

* * *

## 2) Make logs consistently appear in the Logs UI (fix buffering + add structure)

### A) Disable Python buffering (high impact)

A Hugging Face Spaces thread shows `ENV PYTHONUNBUFFERED=1` fixed missing/late output and the author confirms “It worked!” ([Hugging Face Forums](https://discuss.huggingface.co/t/spaces-runtime-logging/139383 "Spaces runtime logging - Spaces - Hugging Face Forums"))

Do this even if you are not using a Docker Space:

- Add a Space variable: `PYTHONUNBUFFERED=1`
- Also use `print(..., flush=True)` for critical lines.

Why this matters: under load, crashes can happen before buffered stdout flushes, so the Logs UI looks empty even though your code “printed.”

### B) Use structured logging so interleaving is readable

Under concurrency, log lines interleave. If you add timestamps + PID + request id, the Logs UI becomes usable.

Minimal pattern:

```python
import logging, sys, uuid

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s pid=%(process)d rid=%(message)s",
    handlers=[logging.StreamHandler(sys.stdout)],
    force=True,
)

def rid():
    return uuid.uuid4().hex[:8]

logging.info(f"{rid()} app_start")

```

This does not “retain” logs, but it makes what you _do_ see much easier to correlate.

* * *

## 3) Stream Space logs to your own terminal (most reliable “display”)

This is the cleanest answer to “logs are in another container / disappeared.” Instead of relying on the web UI, you open the same kind of backend stream and keep it running while you reproduce issues.

A `huggingface_hub` issue documents how to:

1. fetch a Space JWT (`/api/spaces/{space_id}/jwt`)
2. stream logs from `https://api.hf.space/v1/{space_id}/logs/{build|run}` via SSE ([GitHub](https://github.com/huggingface/huggingface_hub/issues/2667 "Method to retrieve jwt token + stream logs from a Space · Issue #2667 · huggingface/huggingface\_hub · GitHub"))

Minimal script (runtime logs):

```python
# deps: requests
import json, requests

SPACE_ID = "alexnasa/ltx-2-TURBO"
jwt = requests.get(f"https://huggingface.co/api/spaces/{SPACE_ID}/jwt").json()["token"]

with requests.get(
    f"https://api.hf.space/v1/{SPACE_ID}/logs/run",
    headers={"Authorization": f"Bearer {jwt}"},
    stream=True,
) as r:
    for line in r.iter_lines():
        if line and line.startswith(b"data: "):
            event = json.loads(line[len(b"data: "):].decode())
            print(event.get("timestamp"), event.get("data"), flush=True)

```

Why this solves your specific pain:

- You can keep it open during heavy usage and catch the error even if the runtime changes.
- The stream can include timestamps even when the UI doesn’t show them. ([Hugging Face Forums](https://discuss.huggingface.co/t/absent-timestamps-in-front-of-each-command-in-logs-window-during-comfyui-run/172005 "Absent timestamps in front of each command in Logs window during ComfyUI run - Spaces - Hugging Face Forums"))
- You can retain logs locally by redirecting output (example: pipe to a file).

* * *

## 4) Show errors where you can’t miss them (during debugging)

### A) Enable Gradio’s `show_error=True` temporarily

Gradio’s `Blocks.launch()` has a documented `show_error` parameter: if True, errors show in an alert modal and browser console. ([gradio.app](https://www.gradio.app/docs/gradio/blocks "Gradio Docs"))

Use it as a debug toggle (turn on only when investigating, because it can reveal stack traces to users).

### B) Use `gr.Error` for controlled messages

Gradio documents raising `gr.Error("message")` to show a custom error modal. ([gradio.app](https://www.gradio.app/docs/gradio/error "Error - Gradio Docs"))

Good pattern:

- Log the full traceback to stdout (`logging.exception(...)`)
- Show a short user-safe `gr.Error(...)` that includes a request id you can search for in logs

* * *

## 5) Optional: SSH into the running container (Dev Mode) for live debugging

If Dev Mode is available for your Space, Hugging Face documents that it lets you connect to the Space container via **SSH** (and VS Code). ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-dev-mode "Spaces Dev Mode: Seamless development in Spaces"))

This is useful when:

- you need to reproduce an error interactively
- you want to run the app manually and observe output in-session

* * *

## What I would do for your Space, specifically (no storage assumptions)

1. Set `PYTHONUNBUFFERED=1`. Confirm the “it printed but I didn’t see it” symptom improves. ([Hugging Face Forums](https://discuss.huggingface.co/t/spaces-runtime-logging/139383 "Spaces runtime logging - Spaces - Hugging Face Forums"))
2. Add structured logs (timestamp + PID + request id).
3. Run the SSE log streamer locally while you stress-test the Space. Keep that terminal output as your ground truth. ([GitHub](https://github.com/huggingface/huggingface_hub/issues/2667 "Method to retrieve jwt token + stream logs from a Space · Issue #2667 · huggingface/huggingface\_hub · GitHub"))
4. Temporarily enable `show_error=True` so exceptions surface immediately in the browser while you debug. ([gradio.app](https://www.gradio.app/docs/gradio/blocks "Gradio Docs"))

* * *

### Summary

- Built-in UI: use **Open Logs** and switch between **Build** and **Container**. ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-sdks-docker-first-demo "Your First Docker Space: Text Generation with T5"))
- Stop “missing” logs: set `PYTHONUNBUFFERED=1` and flush output. ([Hugging Face Forums](https://discuss.huggingface.co/t/spaces-runtime-logging/139383 "Spaces runtime logging - Spaces - Hugging Face Forums"))
- Most reliable display: stream logs via `api.hf.space` SSE using a Space JWT and keep it running. ([GitHub](https://github.com/huggingface/huggingface_hub/issues/2667 "Method to retrieve jwt token + stream logs from a Space · Issue #2667 · huggingface/huggingface\_hub · GitHub"))
- Make errors obvious: temporarily enable Gradio `show_error=True` and use `gr.Error` for controlled messages. ([gradio.app](https://www.gradio.app/docs/gradio/blocks "Gradio Docs"))

---

_[View the full topic](https://discuss.huggingface.co/t/error-debug-logs-in-spaces/172682)._