17 days ago
I'm on Hobby, running a Postgres service, and seeing a recurring pattern where my database briefly refuses connections roughly once a day (often around 10:00 UTC), lasting about 5 minutes, then recovering on its own. External uptime monitoring flags it as a connection timeout every day.
Digging into the Postgres logs, the connection refusals line up exactly with checkpoints whose sync phase stalls badly. Normal checkpoints complete in well under 1 second, but intermittently the sync phase jumps to 30-100+ seconds, and during those windows I see "could not accept SSL connection: Connection reset by peer".
Representative log lines:
checkpoint complete: ... write=0.247 s, sync=0.421 s, total=87.518 s
checkpoint complete: ... write=1.002 s, sync=33.910 s, total=35.791 s
checkpoint complete: ... write=0.599 s, sync=0.068 s, total=105.809 s
could not accept SSL connection: Connection reset by peer (x6 in one second, at the same time)
The write phase is fast and the buffer counts are tiny (single-digit to low-double-digit buffers, kB-scale distance), so this doesn't look like my workload generating heavy write load. It looks like the underlying disk/volume isn't responding during the sync/fsync phase, which stalls the checkpoint and blocks new connections until it clears.
Questions:
- Is this shared-volume disk I/O contention on Hobby? The regular ~10:00 UTC timing makes me wonder if a platform-side backup/snapshot is competing for the same disk.
- Would Pro (or a different storage/volume tier) give better or more isolated disk I/O that would resolve these sync stalls, or is this expected on shared storage regardless of plan?
- Is there anything on my side (checkpoint tuning, etc.) worth trying, or is this fundamentally a storage-provisioning issue?
Impact is currently low (it self-heals and I have a connect-timeout so requests fail fast rather than hang), but the daily connection blip and monitoring noise are worth solving. Postgres image is the standard railwayapp-templates/postgres-ssl, US East region.
Thanks for any insight.
Field selections
- Service: select your Postgres service from the dropdown.
- Visibility: Ask the Community (the one you can use). Note it says "usually answered within 12 hrs" — actually faster than the 48h private option, so no loss there.
1 Replies
17 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 17 days ago
17 days ago
On your questions:
Shared-volume I/O contention is the most likely explanation. Sync-phase stalls with tiny buffer counts (so it's not your write load) strongly point to the underlying storage backend being busy with something external — a scheduled snapshot/backup process is a very plausible cause given the consistent daily timing. I don't have visibility into Railway's internal backup scheduling, so I'd treat this as a hypothesis rather than confirmed — worth asking Railway staff directly (or filing a private ticket in parallel) since only they can confirm what runs on that volume around 10:00 UTC.
Pro vs Hobby storage isolation — I don't have confirmed details on whether Pro volumes sit on dedicated vs shared storage tiers for Railway specifically. If Pro offers better disk I/O isolation, that would explain a fix, but I wouldn't recommend upgrading purely to test this without Railway confirming there's an actual isolation difference — otherwise you might pay for Pro and see the same pattern.
On your side, a few things worth trying while you wait for infra confirmation:
Check pg_stat_bgwriter (checkpoints_timed, checkpoints_req, checkpoint_sync_time) over a few days to see if checkpoint_sync_time consistently spikes at the same time — this quantifies the stall pattern.
If you haven't already, spreading checkpoints more evenly via checkpoint_completion_target (closer to 0.9) can reduce I/O bursts, though it won't fix an external contention source.
Since the stalls line up with SSL connection resets rather than just query timeouts, it's worth checking whether tcp_keepalives_idle/idle_in_transaction_session_timeout settings are masking or worsening the symptom on the client side.
Given the regularity and external correlation, I'd push this toward Railway support directly (even alongside the public thread) — a platform-level scheduling conflict isn't something you can fully diagnose or fix from the Postgres side alone.