Platform Limits & Quotas¶

Quick reference for common Azure App Service platform limits and quota-related behaviors.

Overview¶

graph TD
    A[Subscription Quota] --> B[App Service Plan]
    B --> C[Web Apps]
    C --> D[Instance Scale]
    C --> E[Storage Quota]
    C --> F[Networking Limits]
    C --> G[Request Limits]

How to Read This Page¶

Each figure carries one of three classes, because they do not carry the same authority.

• [Documented]: stated by Microsoft Learn for App Service, with the source in the row. Still source-reviewed only (see the review note at the end), not tested against Azure by this guide.
• [Application or framework]: set by your runtime, web server or framework, not by an App Service platform limit. This page publishes no number for these; see Values this guide does not publish.
• [Measured]: a value observed in a lab. Lab measurements live with their lab and evidence, never in this table.

Request Limits¶

Values this guide does not publish¶

The sources reviewed for this page do not document an App Service-wide value for the first three, so a number here would be an invention. They are [Application or framework] concerns and depend on the runtime, web server and request path.

• Maximum request body size. Request-body limits vary by runtime and web server (for example IIS request filtering on Windows); see Request Limits requestLimits (IIS) for the IIS behavior.
• Maximum URL length. URL limits vary by stack and by front-end and server behavior; the same IIS reference covers the Windows web server.
• Maximum number of app settings. No hard App Service limit is documented; environment-block and runtime constraints can be stack-specific. See Configure an App Service app.
• Filesystem log retention. This one is an App Service logging setting, not an application or framework concern: you choose the number of days, so there is no platform default to publish (see Diagnostics and Retention).

Earlier revisions of this page showed 128 MB, 8192 characters, 10,000 settings and 30-90 days as "typical" values. They were removed because no primary source supports them as App Service limits.

Scale and Plan Limits¶

Always On. The Microsoft Learn limits table marks Always On as supported on Basic, Standard, Premium, and Isolated plans, and not on Free or Shared. Basic therefore supports Always On even though it does not support deployment slots; the two columns above are independent capabilities. [Documented] from the source linked in each row, reviewed 2026-10-24. [Not Proven] by a run on each SKU: this page's values are source-reviewed and were not exercised against Azure.

Storage and File System¶

There is no single persistence rule for /home. What survives a restart depends on the hosting model, so read the row for your model. Each row is [Documented] from the source shown; this guide did not exercise these behaviors against Azure.

Restarts and redeployments are not a retention guarantee. The rows above describe what survives a restart (and, for shared storage, what instances share). They do not promise backup, retention, recovery or an uptime SLA for the files, and this page makes no such claim. Keep application state in a service built for it and do not rely on temporary paths or the container layer.

/home/LogFiles is the documented exception for custom containers (C:\home\LogFiles on Windows): with application logging's File System option enabled, that folder persists across restarts whether or not persistent storage is enabled. Where logs persist they use storage and count against the plan's quota, so large log volume can fill it; this is persistence across restarts, not a retention or backup guarantee.

Proof condition for your own app¶

Treat the table as the documented expectation, not as proof for a particular app. To confirm, check the one setting that decides the Linux custom-container case:

az webapp config appsettings list \
  --resource-group $RG \
  --name $APP_NAME \
  --query "[?name=='WEBSITES_ENABLE_APP_SERVICE_STORAGE'].{name:name,value:value}" \
  --output table

Then verify behavior with an operator-approved test: write a marker file under the path you care about, restart the app, confirm the marker is still there, and, if you run several instances, confirm that a different instance sees it. [Not Proven]: this guide has not run that test for this page, so no observed result is claimed. Record the date, hosting model, runtime, region, SKU and the exact path if you do run it, and keep the observation separate from the documented rows above.

Deployment and Configuration Limits¶

The number of app settings is not listed here; see Values this guide does not publish.

Networking and Connections¶

Diagnostics and Retention¶

Limit-Driven Symptoms¶

• Intermittent outbound failures under load (possible SNAT pressure)
• Sudden 5xx spikes with no code change (plan/resource saturation)
• Failed uploads or deployments due to artifact size
• Missing files due to writing into ephemeral paths
• Slow or dropped long-running HTTP requests over frontend timeout

Run It in the Portal¶

Portal view: Scale up (App Service plan) blade¶

The Scale up (App Service plan) blade is where you compare the plan SKUs that drive most of the limits in the Scale and Plan Limits table above. This capture shows the Hardware view table grouped into Dev/Test, Production, and Legacy, with the selected Premium v3 P0V3 row exposing the per-plan fields that matter operationally: vCPU, Memory (GB), Remote Storage (GB), Scale (instance), and SLA. Because the blade is scoped to the App Service plan rather than the individual web app, it is the right place to confirm whether plan tier and per-instance capacity are part of a saturation or quota problem. Use this view to verify the current plan family and worker size before concluding that a symptom is application-only.

Review Status¶

[Documented] figures were checked against the Microsoft Learn sources in each row on 2026-10-24. That is a source review: this guide did not run these limits against Azure, and a lab measurement would be a separate [Measured] claim recorded with its own evidence. [Not Proven]: any figure not listed here.

See Also¶

• CLI Cheatsheet
• KQL Queries

Sources¶

• Azure App Service Limits (Microsoft Learn)
• App Service Plan Overview (Microsoft Learn)
• Best Practices for App Service (Microsoft Learn)

Language-Specific Details¶

Language/runtime behavior (for example, worker model, memory profile, and startup semantics) can change how these limits are experienced in practice. See:

• Azure App Service Node.js Guide — Reference
• Azure App Service Python Guide — Reference