I wouldn’t rely on a “can/can’t open URL” check here since this can be intermittent depending on routing or temporary container state.

But based on the original symptom (sudden ~20s response times with no code changes), this strongly points to an internal runtime issue rather than Railway edge/networking.

Most likely causes in this pattern are:

• DB connection pool exhaustion (requests waiting for checkout timeout)
• Puma thread saturation vs DB pool mismatch
• Slow/hanging SQL or N+1 query growth
• External API calls without timeouts blocking requests
• Memory pressure leading to GC pauses or unstable performance

If /up is still responding fast, that reinforces that the app is up but real request paths are getting blocked internally.

Best next step is checking Rails logs for a slow request trace and correlating it with ActiveRecord timing + Railway CPU/memory during that window.