Scheduling Azure Container App
Can ZopNight schedule Azure Container App?
Container Apps schedules use the platform's stop operation, deactivating every replica including a minimum-replica floor of 1 or more, the piece consumption-plan autoscaling never removes. A stopped app keeps its ingress URL but returns errors, and KEDA triggers cannot wake it: only the scheduled start does, restoring prior scale behavior.
How the stop works
| Field | Value |
|---|---|
| Behaviour | stopped and started via the Container Apps stop/start operation, deactivating all replicas while stopped. |
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
Doesn’t this platform already scale to zero?
On the consumption plan, yes, provided replicas can reach zero. The gap is the minimum replica count. Apps configured with a floor of 1 or more, usually to dodge cold starts, bill for those replicas around the clock, idle or not. The stop operation is the calendar-shaped answer: warm floor during business hours, genuinely off outside them, without editing scale rules twice a day.
Stop outranks every scale rule
A stopped container app runs zero replicas regardless of HTTP traffic, KEDA queue depth, CPU rules or the configured minimum. Deactivation is absolute in a way autoscaling is not, which is precisely why it needs the matching start: no event can wake a stopped app. A queue that fills at 3am waits until the scheduled start, at which point normal event-driven scaling resumes and drains it.
The front door stays where it was
Ingress configuration, the app’s FQDN and custom domains persist through the stop; callers reach the endpoint and receive errors rather than DNS failures. Uptime checks will fire unless they respect the window. Revisions are untouched. The same active revision serves in the morning, so stop and start is not a deployment event.
Dedicated plan changes the arithmetic
On a dedicated workload profile, billing follows the profile’s provisioned instances rather than per-replica consumption. Stopping apps only saves money to the extent the profile itself can shrink; a profile held at fixed size bills the same with every app stopped. There, schedule the profile capacity story first and the apps second.
Numbers worth running
A consumption-plan app with min replicas 1 spends roughly two-thirds of each week, 118 of 168 hours, billing for a replica that serves nobody, assuming a weekday business-hours pattern. That idle floor, times the number of always-warm microservices in a staging environment, is the schedule’s whole case.