Hi,

My service chic-reverence (project ID: 17854db4-b5b1-4e67-aaf8-27d44ea434d9, service ID: 5a7a8091-e881-45fc-bf11-d4f31abe8581, environment ID: 43bef730-db0d-465c-9ee7-ddd82d693608) seems stuck serving an old container despite multiple deployments marked "Success"/"Active".

Context: the public domain is senzasmartapp.com, and the generated subdomain is chic-reverence-production-a0d0.up.railway.app. The service serves a static file (privacy.html) through a small Node server (server.js) that reads the file directly from disk on every request (fs.readFile, no application-level caching).

What I changed: I committed a change to privacy.html on the main branch of the connected GitHub repo (rachzzr-hash/senza-smart-app-website), commit f23a1267ccd05e87d250223edb7d42c96c44cb47 ("Update privacy.html"), on September 29, 2026.

What I've already tried, with no success:

Multiple manual redeploys (both before and after your incident on September 29 regarding "slow or stuck deployments," status now "Resolved").

Fully disconnecting and reconnecting the GitHub integration.

Confirmed no Volume is attached to the service.

Confirmed "Root Directory" is empty (building from repo root).

Confirmed the connected branch (only one branch exists on the repo).

Build Logs show a copy / /app step that is NOT cached (658ms), so the build does appear to copy fresh content.

Symptom: despite all of this, https://chic-reverence-production-a0d0.up.railway.app/privacy keeps serving the old file content, identical before and after every redeploy — tested both via direct HTTP requests and via a real browser (so it's not a client-side caching issue).

Could you check whether the container actually serving traffic for this service really matches the latest build, or whether there's a stuck container/replica left over from the September 29 incident? A forced restart on the infrastructure side would be much appreciated if possible.

Thanks in advance,

Rachid