# Restart error 503. Factory reset. No rebuild. Same with other space

**URL:** <https://discuss.huggingface.co/t/restart-error-503-factory-reset-no-rebuild-same-with-other-space/173779>\
**Category:** Spaces\
**Created:** [February 26, 2026, 1:29am UTC](https://discuss.huggingface.co/t/restart-error-503-factory-reset-no-rebuild-same-with-other-space/173779 "2026-02-26T01:29:37Z")\
**Posts on this page:** 1\
**Showing post:** 4

<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:** [February 26, 2026, 7:32am UTC](https://discuss.huggingface.co/t/restart-error-503-factory-reset-no-rebuild-same-with-other-space/173779/4 "2026-02-26T07:32:30Z")

</div>

Regarding Spaces that access other sites on the internet, there are cases of intentional restrictions by HF, but in other cases:

* * *

## What “Restart → 503” usually means on Spaces (background)

On Hugging Face Spaces, the “Restart Space” / “Factory reboot” buttons call backend APIs that must be able to (a) schedule your Space, (b) start the container, and (c) observe it becoming _healthy_ (typically: a web server is reachable on the configured port). If any of those phases fail, the UI often collapses it into a generic `503` restart error. ([Hugging Face Forums](https://discuss.huggingface.co/t/having-error-in-restarting-space/173572 "Having error in restarting space - Beginners"))

A “Paused” Space can be either manually paused or effectively auto-stopped after repeated failed starts. In both cases, a restart attempts the same start+health sequence again, and you’ll see the same 503 if the underlying cause hasn’t changed.

Your `Root=…` value is a backend request/trace ID. It’s useful to include when asking Hugging Face staff to check server-side logs for the failed restart call.

* * *

## What I see in your actual Space code (the two biggest “hard blockers”)

### 1) **Port type bug: your server can end up listening on a Unix socket, not a TCP port**

In both Spaces, you compute:

```ts
const PORT = process.env.PORT || 3000

```

and later:

- Space 1: `app.listen(PORT as number, '0.0.0.0', ...)` ([Hugging Face](https://huggingface.co/spaces/nutipaaa/spotify-api-server/blob/main/src/index.ts "src/index.ts · nutipaaa/spotify-api-server at main"))
- Space 2: `app.listen(PORT, ...)` ([Hugging Face](https://huggingface.co/spaces/nutipaaa/spotify-api-server-2/blob/main/src/index.ts "src/index.ts · nutipaaa/spotify-api-server-2 at main"))

**Why this breaks on platforms like Spaces:**

- `process.env.PORT` is **always a string** when it exists (environment variables are strings).
- In Node.js, `server.listen()` has a _different overload_ for strings:  
`server.listen(path[, ...])` starts an IPC server on a **Unix domain socket path** , while `server.listen(port[, host])` starts a TCP server on a **numeric port**. ([Node.js](https://nodejs.org/api/net.html "Net | Node.js v25.7.0 Documentation"))  
So if `PORT` is `"3000"` (string), Node interprets it as a **path** (e.g. a socket file named `3000`), and **your app never opens TCP port 3000**.
- Hugging Face’s proxy/health check expects an HTTP server reachable on the configured TCP port (`app_port`). If no TCP listener appears, the container may be treated as unhealthy → restart attempts fail → you see `503`.

**Important detail for Space 1:** `PORT as number` does **not** convert anything at runtime. Type assertions are erased at compile time. ([microsoft.github.io](https://microsoft.github.io/TypeScript-New-Handbook/everything/ "Handbook Page"))  
So Space 1 is still passing a string when `process.env.PORT` exists.

This single issue can fully explain: “worked, then suddenly died with no code changes” if the platform behavior changed (e.g., the runtime started injecting `PORT` where it previously didn’t), or if your container restarted and picked up a now-present `PORT` value.

You already set `app_port: 3000` in the Space metadata and `EXPOSE 3000` in the Dockerfile, so your **intended** port is clearly 3000. ([Hugging Face](https://huggingface.co/spaces/nutipaaa/spotify-api-server/blob/main/README.md "README.md · nutipaaa/spotify-api-server at main"))

* * *

### 2) **Immediate process exit if secrets are missing**

Both Spaces contain:

```ts
if (!process.env.API_SECRET || !process.env.SP_DC || !process.env.SP_KEY) {
  console.error('Error: Missing required environment variables...')
  process.exit(1)
}

```

([Hugging Face](https://huggingface.co/spaces/nutipaaa/spotify-api-server/blob/main/src/index.ts "src/index.ts · nutipaaa/spotify-api-server at main"))

This means: if any secret is missing, the container **exits immediately** , which is also a classic trigger for “restart → 503” patterns (start → crash loop).

This is especially relevant because:

- Hugging Face explicitly documents that **Secrets are not copied into duplicated Spaces** (variables can be; secrets won’t). ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-overview "Spaces Overview"))  
So your “create the same Space” test will fail fast unless you re-add those secrets in the new Space.
- Any change in secrets/hardware triggers a restart. ([Hugging Face](https://huggingface.co/docs/huggingface_hub/en/guides/manage-spaces "Manage your Space"))

So even if the port bug didn’t exist, the “second Space dies within minutes” is consistent with secrets missing → `process.exit(1)`.

* * *

## Why these two blockers can produce your exact symptoms

### Symptom A: “Space is stuck Paused; restart/factory reboot instantly 503”

- If the container never becomes reachable on the configured port (port bug), Hugging Face can fail the start/health cycle, and the UI reports it as restart 503. ([Hugging Face Forums](https://discuss.huggingface.co/t/having-error-in-restarting-space/173572 "Having error in restarting space - Beginners"))
- If the container exits immediately (missing secrets), the backend sees a crash loop; restart attempts fail similarly.

### Symptom B: “Can’t trigger rebuild; pushing commits doesn’t start rebuild”

Two common explanations in this situation:

1. The rebuild **does start** but fails very quickly (build completes, runtime starts, then immediately fails health check or exits). From the UI it can look like “nothing happens” unless you watch the build/runtime logs.
2. Less commonly: a platform-side incident (build scheduler/proxy) can cause widespread restart/build failures. Hugging Face’s status page is the fastest check. ([status.huggingface.co](https://status.huggingface.co/ "Hugging Face status"))

Given your code, (1) is strongly supported.

* * *

## Concrete fixes (do these first)

### Fix 1: Parse `PORT` into a real number (and validate)

Replace the PORT logic with something that **forces numeric** :

```ts
const portRaw = process.env.PORT ?? "3000";
const PORT = Number.parseInt(portRaw, 10);

if (!Number.isFinite(PORT)) {
  throw new Error(`Invalid PORT: ${portRaw}`);
}

app.listen(PORT, "0.0.0.0", () => {
  console.log(`Server listening on 0.0.0.0:${PORT}`);
});

```

Why this works:

- If the platform sets `PORT="3000"`, you listen on TCP port 3000 (not a socket path).
- If `PORT` is absent, you still bind to 3000.
- Explicit `0.0.0.0` avoids “bind to localhost only” pitfalls that also break reverse proxies. ([Hugging Face Forums](https://discuss.huggingface.co/t/hf-space-stuck-at-starting/170911 "HF Space stuck at Starting"))

### Fix 2: Don’t hard-exit on missing secrets while debugging (optional but practical)

Right now, missing secrets kills the process, which can make recovery harder.

During debugging you can instead:

- start the server anyway,
- expose a `/health` that returns a clear “misconfigured” response,
- and log which keys are missing (without printing secret values).

Example pattern:

```ts
const missing = ["API_SECRET","SP_DC","SP_KEY"].filter(k => !process.env[k]);
if (missing.length) {
  console.error(`Missing env vars: ${missing.join(", ")}`);
}

app.get("/health", (req, res) => {
  if (missing.length) return res.status(500).json({ ok: false, missing });
  res.json({ ok: true });
});

```

Then you can still see logs and verify the port binding, even before secrets are perfect.

### Fix 3: Ensure Docker/Space port alignment stays consistent

You already have:

- `app_port: 3000` in README metadata ([Hugging Face](https://huggingface.co/spaces/nutipaaa/spotify-api-server/blob/main/README.md "README.md · nutipaaa/spotify-api-server at main"))
- `EXPOSE 3000` in Dockerfile ([Hugging Face](https://huggingface.co/spaces/nutipaaa/spotify-api-server/blob/main/Dockerfile "Dockerfile · nutipaaa/spotify-api-server at main"))

Keep that, but the runtime _must_ listen on the same TCP port.

* * *

## Recovery steps when the UI controls are failing

### Option 1: Restart via API (bypasses the UI button)

Hugging Face provides `restart_space()` and runtime management through `huggingface_hub`. ([Hugging Face](https://huggingface.co/docs/huggingface_hub/en/package_reference/space_runtime "Managing your Space runtime"))

If you can run a local script with an HF token, you can attempt:

- `get_space_runtime()` to see current stage/state
- `restart_space()` after you push the port fix

(These calls are documented in the Space runtime reference. ([Hugging Face](https://huggingface.co/docs/huggingface_hub/en/package_reference/space_runtime "Managing your Space runtime")))

### Option 2: Trigger a restart by changing configuration

Any config change (secrets/hardware) triggers a restart. ([Hugging Face](https://huggingface.co/docs/huggingface_hub/en/guides/manage-spaces "Manage your Space"))  
So adding/updating a secret (even re-saving the same one) can force a new start attempt.

### Option 3: If it still fails after the port fix + secrets are set

At that point, include:

- the Space name,
- the approximate time of the failed restart,
- and your `Root=…` trace ID

and ask Hugging Face staff to check server-side restart/build logs. (That trace ID is the best handle you have for backend correlation.)

* * *

## Other plausible contributors (secondary, but worth hardening)

### Playwright resource pressure (can cause “ran fine for days, then dies”)

Running Chromium in containers can hit shared memory / RAM issues over time; Playwright’s Docker guidance and common mitigations include flags like `--disable-dev-shm-usage` (which you already use). ([Playwright](https://playwright.dev/docs/docker "Docker"))  
If you still see slow growth:

- keep concurrency at 1 (you do) ([Hugging Face](https://huggingface.co/spaces/nutipaaa/spotify-api-server/blob/main/src/index.ts "src/index.ts · nutipaaa/spotify-api-server at main"))
- ensure every context/page is closed (you close contexts) ([Hugging Face](https://huggingface.co/spaces/nutipaaa/spotify-api-server/blob/main/src/browser.ts "src/browser.ts · nutipaaa/spotify-api-server at main"))
- consider periodically restarting the browser (you already schedule this) ([Hugging Face](https://huggingface.co/spaces/nutipaaa/spotify-api-server/resolve/main/src/cronjobs.ts?download=true "huggingface.co"))

This is more about preventing future crashes, not the current “won’t restart” state.

* * *

## Similar cases/pitfalls reported by others (patterns that match yours)

These are recurring causes behind “stuck starting / restart 503” on Spaces:

1. **Wrong host/port binding** (server never reachable by proxy) ([Hugging Face Forums](https://discuss.huggingface.co/t/hf-space-stuck-at-starting/170911 "HF Space stuck at Starting"))
2. **Immediate crash on startup** (missing secrets, missing deps, runtime exceptions) ([Hugging Face Forums](https://discuss.huggingface.co/t/having-error-in-restarting-space/173572 "Having error in restarting space - Beginners"))
3. **Docker build/restart loops and 503** reports for Docker Spaces ([Hugging Face Forums](https://discuss.huggingface.co/t/spaces-docker-build-pauses-and-503-error-on-restart/171149 "Spaces Docker Build Pauses and 503 Error on Restart"))
4. **Platform incidents** (less common, but real): check status page before deep-diving ([status.huggingface.co](https://status.huggingface.co/ "Hugging Face status"))

* * *

## High-quality resources (docs/posts/issues) for this exact topic

### Hugging Face (authoritative)

- Docker Spaces docs (ports, `app_port`) ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-sdks-docker "Docker Spaces"))
- Spaces overview (secrets vs variables; secrets not duplicated) ([Hugging Face](https://huggingface.co/docs/hub/en/spaces-overview "Spaces Overview"))
- Managing Space runtime (`restart_space`, `get_space_runtime`, secrets) ([Hugging Face](https://huggingface.co/docs/huggingface_hub/en/package_reference/space_runtime "Managing your Space runtime"))

### Node/TypeScript (explains the port bug precisely)

- Node `server.listen(path…)` vs `server.listen(port…)` overloads ([Node.js](https://nodejs.org/api/net.html "Net | Node.js v25.7.0 Documentation"))
- TypeScript: type assertions don’t change runtime values ([microsoft.github.io](https://microsoft.github.io/TypeScript-New-Handbook/everything/ "Handbook Page"))

### Playwright in Docker (hardening)

- Playwright official Docker docs ([Playwright](https://playwright.dev/docs/docker "Docker"))

* * *

## Bottom line for your case (most likely root cause order)

1. **Port handling bug** : `process.env.PORT` becomes a string, Node treats it as a _socket path_, so the Space never opens TCP `app_port` → health check fails → restart/factory reboot yields 503. ([Hugging Face](https://huggingface.co/spaces/nutipaaa/spotify-api-server/blob/main/src/index.ts "src/index.ts · nutipaaa/spotify-api-server at main"))
2. **Secrets missing on duplicated Space** : duplicated Space doesn’t inherit secrets → your code exits immediately → it fails within minutes. ([Hugging Face](https://huggingface.co/spaces/nutipaaa/spotify-api-server-2/blob/main/src/index.ts "src/index.ts · nutipaaa/spotify-api-server-2 at main"))
3. Secondary: Playwright resource leaks can explain the initial crash trigger, but they don’t explain the “can’t ever become healthy again” as strongly as (1)+(2). ([Hugging Face](https://huggingface.co/spaces/nutipaaa/spotify-api-server/resolve/main/src/cronjobs.ts?download=true "huggingface.co"))

If you apply Fix #1 (parse the port) and ensure secrets are set, the Space should at least progress past “health check can’t reach server,” which is the prerequisite to getting out of the restart-503 loop.

---

_[View the full topic](https://discuss.huggingface.co/t/restart-error-503-factory-reset-no-rebuild-same-with-other-space/173779)._