# Scheduling 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.

Source: https://zop.dev/integrations/azure/postgresql-flexible/schedule
Updated: 2026-08-19

---

## 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.