Error/debug logs in spaces

Spaces
1

When a Space is frequently used, I imagine the number of docker containers get scaled, but when this happens it seems like the logs disappear or get logged in the other container and not displayed in the main one, so I can’t track errors in my Space as I usually do LTX-2 Video [Turbo] - a Hugging Face Space by alexnasa is there a way to display the logs?

1 Like
2

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)

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)

  • 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)
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)

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:

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)

Minimal script (runtime logs):

# 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)
  • 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)

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)

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)

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)
  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)
  4. Temporarily enable show_error=True so exceptions surface immediately in the browser while you debug. (gradio.app)

Summary

  • Built-in UI: use Open Logs and switch between Build and Container. (Hugging Face)
  • Stop “missing” logs: set PYTHONUNBUFFERED=1 and flush output. (Hugging Face Forums)
  • Most reliable display: stream logs via api.hf.space SSE using a Space JWT and keep it running. (GitHub)
  • Make errors obvious: temporarily enable Gradio show_error=True and use gr.Error for controlled messages. (gradio.app)