439 Daily Quota Exceeded

Azure Application Insights returns the unofficial 439 Daily Quota Exceeded status code when a telemetry resource has reached the daily cap on ingested data. The ingestion endpoint rejects new telemetry until the cap resets.

Table of Contents

Usage
Example
How to fix
Code references
See also

Usage

Application Insights SDKs send telemetry in batches with a POST request to the /v2/track path on an ingestion host such as westus2-0.in.applicationinsights.azure.com. Once the resource has used up the daily data volume set in the Azure portal, the endpoint answers with 439 and drops the batch. The JSON body reports zero accepted items, and each rejected item carries statusCode 439 with the message "Daily quota exceeded".

Microsoft documents 439 as a deprecated, legacy quota signal and names 402 as its replacement for the same daily cap condition. The ingestion service still returns 439 on live traffic, so monitoring and log filters need to match both codes. Older SDK source code labels the number TooManyRequestsOverExtendedTime, which separates a spent daily budget from short-term rate limiting with 429.

The code shows up most often in the browser. A page running the Application Insights JavaScript SDK fires the telemetry request in the background, and the cross-origin request appears in the DevTools Network tab with status 439 while the page itself loads normally. Microsoft properties such as bing.com and Bing Webmaster Tools have shown the code this way when their own telemetry resource hit its cap.

Example

A browser on a page using the Application Insights JavaScript SDK sends a batch of telemetry. The resource has passed its daily cap, so the ingestion endpoint rejects every item in the batch.

Request

POST /v2/track HTTP/1.1
Host: westus2-0.in.applicationinsights.azure.com
Origin: https://www.example.re
Content-Type: application/json
Content-Length: 799

[{"name":"Microsoft.ApplicationInsights.Event","iKey":"00000000-0000-0000-0000-000000000000","data":{"baseType":"EventData","baseData":{"name":"page_click"}}}]

Response

HTTP/1.1 439 Daily Quota Exceeded
Content-Type: application/json; charset=utf-8
Access-Control-Allow-Origin: *
Server: Microsoft-HTTPAPI/2.0

{
  "itemsReceived": 1,
  "itemsAccepted": 0,
  "appId": null,
  "errors": [
    {
      "index": 0,
      "statusCode": 439,
      "message": "Daily quota exceeded"
    }
  ]
}

How to fix

A 439 seen on someone else's website needs no action. The error belongs to the site operator's telemetry budget, and the visible page keeps working. The rest of this section applies to the owner of the Application Insights resource.

Check the daily cap in two places. A workspace-based Application Insights resource has a cap on the component under Usage and estimated costs > Daily cap, and a second cap on the linked Log Analytics workspace. The effective limit is the lower of the two, so raising only one setting leaves the other in force. Resources created from Visual Studio start with a small default cap of about 32 MB per day, intended for testing and often forgotten in production.

Find the source of the volume before raising the cap. The Usage table in Log Analytics breaks ingestion down by data type:

Usage
| where TimeGenerated > ago(7d) and IsBillable == true
| summarize SizeGB = sum(Quantity) / 1000 by DataType, bin(TimeGenerated, 1d)
| order by TimeGenerated desc

Common causes include a new release logging every dependency call, high-cardinality custom metrics, verbose trace logging left on after debugging, and several applications sharing one connection string. All senders using the same instrumentation key count against the same cap.

Reduce volume with sampling. The classic SDKs offer adaptive and fixed-rate sampling, and the Azure Monitor OpenTelemetry distro accepts a samplingRatio option. Ingestion-time transformations on the workspace drop unneeded columns or rows before the data counts as billable.

Wait for the reset when the spike was a one-off. Ingestion resumes at the reset hour shown on the daily cap page. The hour differs per workspace and is not configurable. Telemetry rejected before the reset is lost and not recoverable.

Set an alert to catch the condition early. A log search alert on _LogOperation | where Category =~ "Ingestion" | where Detail contains "OverQuota" fires when a workspace reaches its cap, and classic resources emit an Activity log event named "Application Insights component daily cap reached". Alert on both 402 and 439 in SDK self-diagnostics, since either code signals the same condition.

Code references

The classic .NET SDK names the code as an internal constant and pauses sending on receipt, discarding buffered and stored telemetry until the backoff period ends.

.NET (Application Insights SDK)

ResponseStatusCodes.ResponseCodeTooManyRequestsOverExtendedTime

The JavaScript SDK treats 439 as a final failure and does not retry the batch. The Python Azure Monitor exporter groups 439 with 402 as a quota signal and marks 439 as legacy.