ok

any news?

Update: redeploy now FAILED with zero build/deploy logs — the service can't be provisioned, looks like the volume can't be

mounted/scheduled on a healthy host. The previous running deployment was replaced, so Postgres is now fully DOWN (not just

degraded). Please migrate the volume to a healthy host ASAP — data is intact on the volume, we just need it remounted.

news?

Confirmed: every redeploy/rollback gets stuck in DEPLOYING on the same host (66.33.22.226) and never comes up. The volume

▎ appears pinned to a degraded host. Postgres is fully DOWN. Please force-migrate the volume to a healthy host — this is a

▎ production outage, data is intact on the volume.

This looks like the SAME hardware-failure incident reported in another

Central Station thread today (Postgres online but connections time out with

"Connection terminated unexpectedly", started ~2026-06-19 09:00 UTC, restart

doesn't help). Our Postgres is on host 66.33.22.226 (service e3431af7-...).

Can you confirm our service is part of the same hardware incident and is being

restored? We'll stop redeploying and wait for auto-resume as advised.

Hi Eric — apologies for the outage and the silence. You diagnosed this correctly: it was a degraded host affecting volume I/O, the same class of hardware issue several customers hit on June 19. Your Postgres recovered once the host was remediated — the latest deployment succeeded at 18:00 UTC on June 19, your data is fully intact (volume mounted cleanly, ~1.2 GB present, nothing lost), and your other production services are running. Can you confirm everything looks healthy from your end? One note for next time: rapid redeploy/rollback cycles during a host issue can actually slow recovery, so when a database is stuck in DEPLOYING with this signature, the safest move is to stop redeploying and let us remediate the host. For a production-critical Postgres it's also worth looking at our high-availability Postgres setup, which keeps a replica on a separate host. Sorry again for the disruption.