Scheduling Azure Function App
Can ZopNight schedule Azure Function App?
Stopping a Function App through the Web Apps stop operation takes it fully offline and every trigger goes silent. An App Service plan bills by the plan, not the app, so a stopped app on a dedicated or Premium plan saves $0 unless the plan itself shrinks or hosts nothing else.
How the stop works
| Field | Value |
|---|---|
| Behaviour | stopped and started via the Web Apps stop/start operation, taking the app fully offline 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
What the stop actually silences
The Web Apps stop operation takes the Function App offline completely: HTTP endpoints stop answering, timer triggers stop firing, queue and event triggers stop processing. As a behavioral switch it is total. As a cost switch it does almost nothing by itself, and that gap is the whole story of scheduling this resource.
Plans bill, apps do not
On dedicated and Premium plans, the meter is the plan’s instances. Those instances bill identically whether the apps on them are running or stopped. A stopped Function App on an EP1 plan leaves the EP1 charge exactly where it was. The money moves only when the plan does: scaled down on the same calendar, or emptied entirely so it can be deleted. On the Consumption plan the question inverts: execution is the meter, so an idle function was already costing nothing to leave running.
So the schedule is about behavior
Where the stop shines is control. A staging app that must not process the production queue out of hours, an integration that hammers a partner API that meters by call, a function that must be provably inert during a nightly data migration. The stop makes those windows enforceable rather than advisory.
Queues grow, timers do not catch up
Messages keep arriving while the app is stopped and wait in their queues; the morning start processes the backlog, so size the first hour’s capacity for it. Timer triggers behave differently: missed occurrences are not replayed one by one, and at most a single catch-up run covers the gap. A timer that fires 12 times overnight will not fire 12 times at 8am.
Restart is the easy part
Starting a Function App takes seconds to moments, not minutes: no capacity requests, no provisioning. The runtime rehydrates and triggers reconnect. The engineering effort belongs on the plan-level cost question and the backlog math, not on the start cron’s timing.