Project: celebrated-adaptation

Service: faculty-allocator

Environment: production

Public domain: faculty-allocator-production.up.railway.app

Service ID: 942ae61a-381c-4631-aec0-58b74c86e7c4

Environment ID: bf1ff0d1-6f34-4ca9-9945-3023f2c99e78

Description:

Our service intermittently fails to respond to requests via the public domain, even though the container is confirmed healthy and DNS resolves correctly worldwide. This is not a crash or app-level bug — the container itself is up and serving requests internally.

Evidence gathered:

1. DNS check (dnschecker.org): all-green resolution globally for faculty-allocator-production.up.railway.app.

2. Internal health check via railway ssh, run directly inside the container:

   python3 -c "import urllib.request; print(urllib.request.urlopen('http://localhost:8080/docs').status)"

   → returned 200 (app is healthy and listening on the correct port).

3. Deploy logs show successful requests reaching the app at 12:56:25 (two GET /api/auth/me requests, both correctly returned 401 Unauthorized — proof the app was reachable and responding through the public domain at that time).

4. Minutes later (~13:04), a request to the same public domain (POST /api/auth/login, plus its OPTIONS preflight) hung for ~9 seconds and then failed in-browser as "CORS request did not succeed" — but critically, this request never appears anywhere in the Railway deploy logs. If it had reached the container, we'd expect to see a log line (as we did for the earlier 401s). Its complete absence from logs indicates the request never reached the container at all — it appears to have failed at the edge/proxy layer before reaching our app.

5. This is intermittent, not constant: the same domain worked minutes earlier and has worked on previous days after similar periods of inactivity, sometimes requiring a domain regeneration or redeploy to recover.

6. Public Networking target port is correctly configured (8080), matching what Uvicorn binds to via $PORT.

What we've already ruled out:

• App crash (container logs show clean startup, no errors)
• Wrong port/start command (confirmed correct via Settings → Deploy)
• DNS issue (confirmed resolving globally)
• Local network/device issue (reproduced from a separate device on mobile data)
• Railway status page shows no reported incidents

Request:

Could you check the edge/proxy routing history for this service around 13:04 (IST) today, July 18, 2026? We'd like to understand why requests to the public domain are intermittently not reaching a container that is otherwise confirmed healthy, and whether this is related to idle/cold-start behavior on our current plan.

Happy to provide additional logs or reproduce on request.