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

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

---

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