We’re seeing what looks like the same pattern on our Railway-hosted Express/Node backend.

Region/platform: Railway app service with MongoDB Atlas backend

Started noticing: after our June 3 deploy, but symptoms continued well beyond normal warmup.

Symptoms:

• Intermittent very slow API responses, especially authenticated writes/actions.
• POST /api/auth/login took 15s and later 42s.
• POST /api/forms/:id/publish took 42s.
• PATCH /api/forms/:id/draft/autosave took 85s and returned 409.
• One public form submit took 36s; another took 282s and ended as client closed/499.
• Several auth refresh requests logged 499s after 17s-107s.
• CPU and memory were very low during the window: roughly 0.02 vCPU and ~400 MB RAM on an 8 GB limit.
• Live health checks were fast before/after the slow cluster.
• MongoDB Atlas looked healthy from our side: ping/query timings around tens of ms, no active long-running ops, no index builds, small collections.

We also saw lots of long /socket.io/ polling/upgrade requests, which can distort aggregate HTTP percentiles, but the raw REST logs show real slow login/publish/form-submit requests too.

This does not look like sustained app CPU/RAM pressure, database saturation, or normal post-deploy warmup. It feels like intermittent ingress/proxy/network delay or request handling delay outside the obvious app resource metrics.

Railway status currently says operational, so I’m mainly adding this as another datapoint: low app resource usage, healthy DB checks, but sporadic 30s-200s API waits on POST/PATCH/auth flows. Happy to provide timestamps/deployment IDs if helpful.