Scheduling Azure Database for PostgreSQL Flexible Server
Can ZopNight schedule Azure Database for PostgreSQL Flexible Server?
PostgreSQL Flexible Server restarts itself 7 days after any stop, so only recurring schedules keep it reliably off. Stops apply solely from the Ready state, no automated backups are taken while stopped, which leaves a gap in point-in-time-restore coverage, and storage continues billing at its provisioned size.
How the stop works
| Field | Value |
|---|---|
| Behaviour | stopped and started via the Flexible Server API, but only when the server is in the Ready state. |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
Seven days, then Azure intervenes
A stopped PostgreSQL Flexible Server is on a one-week timer: the platform restarts it after 7 days to keep maintenance flowing. A recurring schedule resets that timer at every stop and never collides with it. The one-off manual stop is the trap. A server paused during a migration freeze resurfaces the next week, billing, unnoticed until the invoice.
The backup gap nobody mentions
While the server is stopped, automated backups do not run. For an overnight window that means little, since the evening’s last backup covers it. For longer stops the point-in-time-restore window develops a hole, and a server stopped Friday to Monday has no Saturday or Sunday restore points. Teams with strict RPO expectations should either accept that gap explicitly or keep the schedule to short cycles.
Ready-state gating and what a skip means
Stops fire only when the server reports Ready. Anything else (an in-progress backup, maintenance, a pending scale) causes a soft skip and a full-price night. An occasional skip is noise; a nightly one means the stop cron sits inside the server’s maintenance or backup window and should move.
What the invoice shows while stopped
Compute drops off; storage does not. The provisioned disk bills for its full size every hour of the stop, as does backup storage above the included amount. On small burstable SKUs with big disks, storage can be most of the bill, so check the split before promising the schedule will halve anything.
Waking up is not free of friction
Post-start, shared buffers are cold, autovacuum picks up where it left off, and applications holding pooled connections reconnect with a burst of errors if they lack retry logic. Give the start cron a head start on the first morning job, and let a warm-up query touch the hot tables if the first user is latency-sensitive.