Always On is an App Service setting that keeps a web app loaded even when it has not received traffic for a while. Without it, an idle app can be unloaded and then start slowly when the next request arrives. Always On is useful for production sites, APIs, background tasks, and apps with scheduled work. It does not replace good health checks or scaling, but it helps avoid avoidable cold-start behavior caused by platform idle unloading.
App Service Always On, always-on setting, keep warm setting
Difficulty
intermediate
CLI mappings
3
Last verified
2026-05-10
Microsoft Learn
Always On is an Azure App Service platform setting that keeps an app loaded and prevents it from being unloaded after idle periods, helping reduce cold starts and background-job interruptions.
Technically, Always On is a platform configuration option for an App Service app. It appears under general settings and can also be set with Azure CLI using web app configuration commands. The setting keeps the application process warm by preventing idle unload behavior on supported App Service plan tiers. It interacts with hosting plan, worker process, deployment slots, startup time, application initialization, and background workloads. Operators inspect the setting alongside plan SKU, app state, health checks, and logs.
Why it matters
Always On matters because a production web app can appear healthy but still deliver a poor first request after idle time. Cold starts are especially painful for APIs, authentication-heavy apps, applications with dependency initialization, and sites serving sporadic but important traffic. The setting gives operators a simple control to improve readiness without adding artificial ping jobs. It also teaches learners an App Service principle: platform configuration affects application behavior, and performance problems are not always caused by code or database latency. It also gives learners a concrete way to connect architecture diagrams, deployed resources, and operator decisions. It also gives learners a concrete way to connect architecture diagrams, deployed resources, and operator decisions.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
You see it in App Service configuration when a web app must stay warm so background jobs, startup code, or HTTP endpoints avoid cold idle behavior.
Signal 02
It appears during performance reviews when operators compare first-request latency, health checks, and restart behavior against the App Service plan tier. during governed production operations
Signal 03
It shows up in cost discussions because keeping apps warm is tied to paid App Service plans, not free or shared experimental hosting. during governed production operations
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Keep an App Service app warm so first-request latency is lower after idle periods.
Support background jobs, hosted services, and scheduled tasks that need a continuously loaded app.
Verify production app configuration through CLI before a performance or reliability review.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
App Service API warm availability
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
BrightPath Logistics ran a route-planning API on Azure App Service that slowed down after idle periods. Dispatchers needed consistent response times at the start of each shift.
🎯Business/Technical Objectives
Keep the production API warm during low-traffic periods.
Reduce first-request latency below two seconds.
Avoid adding unnecessary scale-out instances for a warmup problem.
Document the setting for operations and cost review.
✅Solution Using Always On
The application team enabled Always On for the production App Service plan and verified that the plan tier supported the setting. They kept health checks and Application Insights availability tests in place so the site was not merely warm but also observable. Azure CLI was added to the runbook to confirm the alwaysOn property, plan SKU, slot configuration, and recent restarts. The team avoided enabling the setting on temporary test apps, where idle shutdown was acceptable. For deployments, staging slots warmed before swap, while production stayed responsive. Operations reviewed CPU, memory, and request latency after the change to confirm that the issue was cold startup rather than a dependency bottleneck.
📈Results & Business Impact
First-request latency fell from 14 seconds to 1.6 seconds at shift start.
Dispatcher complaints dropped by 43 percent during the first month.
The team avoided a scale-out increase that would have raised monthly hosting cost by 28 percent.
Runbook checks made the setting visible during every App Service readiness review.
💡Key Takeaway for Glossary Readers
Always On is useful when an App Service app must stay responsive even when natural traffic is too low to keep it warm.
Case study 02
Healthcare portal background jobs
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
CareSpring Clinics hosted a patient portal on App Service with lightweight background tasks for appointment reminders. The tasks became unreliable when the app went idle overnight.
🎯Business/Technical Objectives
Keep reminder processing active outside business hours.
Reduce missed patient notification batches.
Verify the setting through repeatable CLI checks.
Avoid moving simple background work to a new platform prematurely.
✅Solution Using Always On
Engineers enabled Always On for the portal’s production App Service plan and confirmed the reminders were suitable for the hosted app pattern. They reviewed app settings, slot behavior, health checks, and Application Insights traces to ensure the worker logic ran predictably after warm restarts. Azure CLI output for site configuration was captured in the operations guide, including alwaysOn status and plan tier. The team also added alerts for failed reminder batches so Always On would not hide application-level errors. Nonproduction slots were configured separately because some test environments did not need continuous warming.
📈Results & Business Impact
Missed reminder batches decreased by 79 percent over six weeks.
Support calls about appointment notifications fell by 22 percent.
The team postponed a larger worker-service migration until the portal backlog justified it.
Operations gained a simple check to confirm the setting after plan or slot changes.
💡Key Takeaway for Glossary Readers
Always On can stabilize App Service workloads that depend on continuous host availability, but it should be paired with health and job monitoring.
Case study 03
SaaS admin console readiness
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Northwind Metrics offered a low-traffic admin console used during customer escalations. Engineers found the console often paid a cold-start penalty exactly when support needed speed.
🎯Business/Technical Objectives
Keep the admin console responsive for rare but urgent use.
Measure latency improvement without changing application code.
Limit the setting to production and staging slots only.
Give support a visible readiness signal during escalations.
✅Solution Using Always On
The SaaS team enabled Always On for the admin console’s production App Service and staging slot. They left developer environments idle to control cost. Health checks were configured against a lightweight endpoint, and Application Insights tracked cold-start-like latency before and after the change. The deployment pipeline used Azure CLI to verify alwaysOn after slot swaps, because a configuration drift had previously disabled the setting. Support dashboards included availability-test status so responders could confirm the console was reachable before joining an escalation. The team also reviewed memory use to ensure keeping the app warm did not reveal hidden leaks.
📈Results & Business Impact
Median first-page response time improved from 9.8 seconds to 1.2 seconds.
Support escalation setup time dropped by 30 percent.
No additional App Service instances were required to meet the readiness target.
Configuration drift was caught twice by the post-deployment CLI check.
💡Key Takeaway for Glossary Readers
Always On is a small configuration choice that can matter greatly for low-traffic but business-critical App Service endpoints.
Why use Azure CLI for this?
Azure CLI is useful for Always On because it turns a portal setting into repeatable evidence. Operators can inspect scope, status, parameters, and effective configuration from scripts, compare environments, and save output for change control. For this term, CLI is especially helpful when troubleshooting across subscriptions or proving that the deployed resource matches the runbook.
CLI use cases
Inventory the current Always On configuration and export it for review evidence.
Compare portal-visible settings with command output before a production change.
Troubleshoot deployment, policy, identity, monitoring, cost, or scaling symptoms from a repeatable shell.
Automate recurring checks so the Always On standard does not depend on manual portal clicks.
Before you run CLI
Confirm the active tenant, subscription, resource group, and target scope before running commands.
Verify that your account has read permissions, and use contributor-level access only for approved changes.
Choose an output format such as table for review or json for scripts, evidence, and automation.
Check whether the command is read-only, mutating, security-impacting, or cost-impacting before execution.
What output tells you
Names, IDs, scopes, regions, modes, or status fields identify which Always On resource the command actually inspected.
Configuration fields reveal whether the deployed setting matches the intended architecture or governance baseline.
Missing, null, disabled, or empty values usually point to an unconfigured feature, wrong scope, or stale assumption.
JSON output can be saved as change evidence and compared against previous releases or policy reviews.
Mapped Azure CLI commands
Always On operational checks
diagnostic
az webapp config show --resource-group <group> --name <app> --query alwaysOn
az webapp configdiscoverWeb
az webapp config set --resource-group <group> --name <app> --always-on true
az webapp configconfigureWeb
az webapp show --resource-group <group> --name <app> --query "{state:state,plan:serverFarmId}"
az webappdiscoverWeb
Architecture context
Technically, Always On is a platform configuration option for an App Service app. It appears under general settings and can also be set with Azure CLI using web app configuration commands. The setting keeps the application process warm by preventing idle unload behavior on supported App Service plan tiers. It interacts with hosting plan, worker process, deployment slots, startup time, application initialization, and background workloads. Operators inspect the setting alongside plan SKU, app state, health checks, and logs.
Security
Security considerations are indirect. Always On keeps the app process active, so secrets, managed identity access, background jobs, and outbound connections may remain in use more consistently. Teams should ensure configuration secrets are stored safely, preferably through Key Vault references where appropriate, and that background tasks do not perform sensitive actions without monitoring. Access to change the setting should be limited because turning it off can affect availability. Always On should be paired with secure logs, TLS, health checks, and least-privilege identity. Reviewers should confirm permissions, scopes, logs, and exception paths before trusting the control in production. Reviewers should confirm permissions, scopes, logs, and exception paths before trusting the control in production.
Cost
Always On does not usually create a separate line-item charge, but it requires an App Service plan tier that supports the setting and keeps the app continuously loaded. That can influence SKU choices and prevent aggressive idle savings strategies. For production workloads, the cost is often justified by lower latency, fewer missed background actions, and better user experience. For dev or test apps, leaving Always On enabled can waste capacity. FinOps review should separate critical readiness from convenience. FinOps review should separate direct platform charges from indirect labor, delivery delay, and risk-reduction value. FinOps review should separate direct platform charges from indirect labor, delivery delay, and risk-reduction value.
Reliability
Reliability improves when the app stays warm enough to respond quickly and keep scheduled or background work from being interrupted by idle unloading. Always On is not high availability by itself; it does not add instances, zones, backups, or deployment safety. Teams still need health checks, scaling rules, slot swaps, and restart monitoring. The reliable pattern is to enable Always On for production workloads that need continuous readiness, then verify startup, dependency health, and recovery behavior after restarts or deployments. The safest pattern is tested change windows, documented rollback, and monitoring that proves the expected behavior. The safest pattern is tested change windows, documented rollback, and monitoring that proves the expected behavior.
Performance
Performance impact is mainly first-request responsiveness. By keeping the app process loaded, Always On can reduce cold-start delays caused by idle unloads, dependency initialization, and framework startup. It does not fix slow code, undersized plans, bad database queries, or network bottlenecks. Operators should compare startup duration, request latency, and restart frequency before and after enabling it. The setting performs best when combined with suitable plan sizing, health checks, warmup behavior, caching, and measured dependency readiness. Performance review should measure real latency, throughput, startup time, or response effort instead of assuming impact. Performance review should measure real latency, throughput, startup time, or response effort instead of assuming impact.
Operations
Operations teams check Always On during performance reviews, incident response, and app configuration baselines. CLI can show whether it is enabled and set it consistently across environments. Runbooks should identify which apps require Always On, which plan tiers support it, and how the setting interacts with deployment slots or background jobs. If users report slow first requests, operators should inspect app restarts, plan scaling, cold-start logs, and dependency initialization before assuming the setting alone will solve the issue. Good operations practice records owner, scope, command evidence, and the first troubleshooting steps in the runbook. Good operations practice records owner, scope, command evidence, and the first troubleshooting steps in the runbook.
Common mistakes
Assuming the Always On setting exists at every scope or plan tier without checking the actual deployed resource.
Running commands in the wrong subscription because Azure CLI context was not confirmed first.
Treating portal labels as enough evidence instead of validating resource IDs, parameters, and effective state.
Changing production configuration without checking blast radius, rollback path, and dependent services.