I saw similar failures again. Can you please stabilize your network?

Hi PG, thanks for the report and for the timestamps.

I checked our incident history against the two windows you described (≈19:05 UTC on June 6, and the recurrence around 03:47 UTC on June 7) and there were no platform incidents open in either window. For reference, the nearest networking-related incidents were both earlier and already resolved by then:

• Private Networking degraded in Southeast Asia (Singapore) — resolved 17:51 UTC, June 5
• Private Networking in US West — resolved 18:11 UTC, June 4

There was also a brief storage event on June 7 (01:10–02:03 UTC), but it was confirmed to have had no impact on running workloads, and it had ended well before the recurrence you saw.

I also pulled the runtime logs for your Primary service across both windows and it was running steadily the whole time — no crashes, restarts, or networking errors on our side (the only log noise is an n8n trust proxy / X-Forwarded-For validation warning, which is an app-config notice, not a connectivity issue).

To help me dig further, could you share:

1. How you're reaching the service when it times out — the public *.up.railway.app domain / a custom domain, or private networking (*.railway.internal) between your services?
2. The exact error your monitor records (connection refused, TLS handshake timeout, 503, first-byte timeout, etc.) and the precise timestamp(s) with timezone for the most recent occurrence.
3. Whether it's inbound (requests reaching the service) or outbound (the service reaching an external/database host) that fails.

That'll let me trace the specific path and check edge/routing telemetry for your region at the exact moment. Appreciate your patience.