Azure App Service Linux F1 repeatedly enters QuotaExceeded; Kudu returns HTTP 403 despite zero reported usage

Keep the app stopped until the F1 quota reset has passed, then start it once without deploying; if UsageState remains Exceeded, collect diagnostics and escalate because the portal does not expose a more detailed historical quota-enforcement record.

What the state and HTTP 403 mean

On Free and Shared plans, App Service enforces five app-level quotas:

• CPU (Short): five-minute window.
• CPU (Day): resets every 24 hours at midnight UTC.
• Memory: exceeding it stops the app temporarily.
• Bandwidth/Data Out: resets every 24 hours at midnight UTC.
• Filesystem: writes fail when full. ^1^

For F1, the documented limits include:

• 3 CPU minutes per five-minute interval.
• 60 CPU minutes per day.
• 1,024 MB memory per App Service plan over one hour.
• 165 MB bandwidth.
• 1 GB storage. ^2^

Because filesystem usage was only about 114 MiB and writes initially proceeded, filesystem quota is not indicated by the supplied evidence. The likely categories are CPU Short, CPU Day, memory, or bandwidth, but the displayed state alone cannot distinguish them: UsageState only reports NORMAL or EXCEEDED. ^3^

When CPU or bandwidth is exceeded, App Service stops the app until reset and incoming requests return HTTP 403. A quota-disabled Kudu/SCM endpoint can therefore return the same stopped-site response; it should not initially be treated as a separate authentication failure. Your present administrative stop also independently makes a stopped-site 403 expected. ^4^

A zero value shown later does not establish that no quota was exceeded earlier. It is a current value for the chart’s measurement interval, whereas enforcement could have occurred in an earlier short window. Recent reports describe the same Linux F1 combination—QuotaExceeded, low or zero visible usage, and Kudu 403—and recommend waiting through the reset before escalating a state that remains stuck. ^5^

Could deployment and failed startups account for it?

They could account for CPU consumption, but the available records do not prove which counter triggered enforcement.

The initial deployment copied 11,585 files through Kudu, while repeated container launches executed Node.js until failure. App Service metrics include SCM/Kudu requests, and CPU Time is the relevant CPU metric for Free and Shared plans. Consequently, a large deployment plus repeated startup attempts is consistent with exhausting F1’s small CPU windows. It does not prove that deployment activity, rather than runtime startup, bandwidth, or a stale platform state, caused this occurrence. ^1^

The MODULE_NOT_FOUND and exit code 1 are a separate application-startup failure. They can create repeated startup work, but MODULE_NOT_FOUND does not itself identify the quota.

Recovery before another deployment

1. Leave the app stopped through midnight UTC.
   This covers the daily CPU and bandwidth reset; the short CPU quota resets every five minutes. Since restart and stop/start already failed, do not repeat them before that boundary.
2. After the reset, open App Service → App Service Plan → Quotas.
   Record each chart’s name, reset interval, current limit, current value, and “resets in” value before starting the app. ^1^
3. Start the app once, without deploying.
   Observe whether it changes to Running / Normal. If it immediately returns to QuotaExceeded, stop it again; repeated retries can consume another short CPU window.
4. Run portal diagnostics for the event period.
   Go to App Service → Diagnose and solve problems and review:
   • Availability and Performance → Web App Down
   • CPU Usage
   • Memory Usage
   • Application Logs
   • Linux - Number of Running Containers
   • Deployment → Application issues post deployment
   Also review the app’s Activity log around 11:11–11:30 UTC. App Service diagnostics is most useful for events within the last 24 hours. ^6^
5. Correct the package before the next start/deployment.
   • Capture the complete missing-module name locally or from the retained startup log.
   • Verify it is in dependencies, not only devDependencies, if required at runtime.
   • Test the exact command node hosting/crm-worker/host.mjs against the package contents.
   • Build the ZIP from the project root, with the project files at the ZIP root rather than inside an enclosing directory.
   • With build automation disabled, ensure every required runtime file and dependency is already present. Node apps must be deployed with their required npm dependencies. ^7^
6. Retain WEBSITE_RUN_FROM_PACKAGE=1 for the next clean deployment.
   This mounts the ZIP as read-only wwwroot, avoids partially updated application trees, and ensures only a complete package runs. The app must not write runtime data beneath wwwroot. ^8^

If it remains exceeded after reset

Either scale the App Service plan above Free/Shared or open an Azure support request. Scaling removes these Free/Shared runtime quotas; waiting and scaling are the documented recovery choices. ^4^

Include:

• App, App Service plan, region, and SKU.
• Exact UTC timeline.
• State and UsageState transitions.
• Screenshots/exports of every quota chart and reset value.
• Activity Log and diagnostic results.
• Deployment ID or correlation ID, HTTP 504/403 responses, and container-start logs.
• The fact that the state persisted beyond both the five-minute and midnight-UTC reset boundaries.

Ask support to identify the specific internal quota counter and measurement window that set UsageState=Exceeded, and to check for stale quota enforcement if every exposed counter is normal.

References

1. Azure App Service quotas and metrics
2. Azure subscription and service limits, quotas, and constraints
3. UsageState Enum-
4. "Error 403 - This web app is stopped" message
5. Azure App Service Free F1 Linux stuck in QuotaExceeded despite low ...
6. Diagnostics in Azure App Service
7. Configure a Node.js app for Azure App Service (platform-linux)
8. Run your app in Azure App Service directly from a ZIP package