A harbor-ferry schedule site on a lower-tier App Service plan sleeps after idle periods, so the first morning commuter hits a long cold start. What should the developer enable, and what constraint applies?

On App Service, idle sites on lower-tier plans can unload the worker process, so the first morning ferry-schedule visitor pays a cold-start penalty. Always On keeps the site loaded so the schedule board does not boot from scratch for the first rider, but the setting is not available on every plan SKU—exactly the constraint the harbor team must recognize when enabling it. Choosing Always On without checking the plan is a common false comfort on the exam.

Continuous WebJobs do not replace Always On, and Always On is not reserved only for Azure Functions Premium plans. Application Insights availability tests probe URLs on a schedule; they are useful uptime checks but are not the App Service switch that keeps the worker process loaded between real visitor requests. Switching the site to Azure Container Instances with a restart policy of Always abandons App Service rather than fixing cold start with the platform’s Always On feature, and it changes the entire hosting model.

Exam caveat: Always On requires a plan that supports it (commonly Standard and higher in classic guidance—verify current SKU documentation). On plans without Always On, expect unload behavior after idle timeouts unless you change SKU, accept cold starts, or use another keep-warm strategy that still fits App Service.

Operational check: confirm the plan SKU exposes Always On in the configuration blade, enable it, idle the site beyond the previous unload window, hit the ferry schedule URL, and measure that the first request no longer shows the long cold-start delay while the worker remains loaded.