Azure Monitor service limits
This article lists limits in different areas of Azure Monitor.
Alerts
| Resource | Default limit | Maximum limit |
|---|---|---|
| Metric alerts (classic) | 100 active alert rules per subscription. | Call support |
| Metric alerts | 5,000 active alert rules per subscription in Azure public, Azure China 21Vianet and Azure Government clouds. If you are hitting this limit, explore if you can use same type multi-resource alerts. 5,000 metric time-series per alert rule. |
Call support. |
| Activity log alerts | 100 active alert rules per subscription (cannot be increased). | Same as default |
| Log alerts | 1000 active alert rules per subscription. 1000 active alert rules per resource. | Call support |
| Alert rules and Action rules description length | Log search alerts 4096 characters All other 2048 characters |
Same as default |
Alerts API
Azure Monitor Alerts have several throttling limits to protect against users making an excessive number of calls. Such behavior can potentially overload the system backend resources and jeopardize service responsiveness. The following limits are designed to protect customers from interruptions and ensure consistent service level. The user throttling and limits are designed to impact only extreme usage scenario and should not be relevant for typical usage.
| Resource | Default limit | Maximum limit |
|---|---|---|
| GET alertsSummary | 50 calls per minute per subscription | Same as default |
| GET alerts (without specifying an alert ID) | 100 calls per minute per subscription | Same as default |
| All other calls | 1000 calls per minute per subscription | Same as default |
Action groups
| Resource | Default limit | Maximum limit |
|---|---|---|
| Azure app push | 10 Azure app actions per action group. | Same as Default |
| 1,000 email actions in an action group. No more than 100 emails in an hour. Also see the rate limiting information. |
Same as Default | |
| ITSM | 10 ITSM actions in an action group. | Same as Default |
| Logic app | 10 logic app actions in an action group. | Same as Default |
| Runbook | 10 runbook actions in an action group. | Same as Default |
| SMS | 10 SMS actions in an action group. No more than 1 SMS message every 5 minutes. Also see the rate limiting information. |
Same as Default |
| Voice | 10 voice actions in an action group. No more than 1 voice call every 5 minutes. Also see the rate limiting information. |
Same as Default |
| Webhook | 10 webhook actions in an action group. Maximum number of webhook calls is 1500 per minute per subscription. Other limits are available at action-specific information. | Same as Default |
Autoscale
| Resource | Default limit | Maximum limit |
|---|---|---|
| Autoscale settings | 100 per region per subscription. | Same as default |
| Autoscale profiles | 20 profiles per autoscale setting. | Same as default |
Data collection rules
| Limit | Value |
|---|---|
| Maximum number of data sources | 10 |
| Maximum number of counter specifiers in performance counter | 100 |
| Maximum number of facility names in Syslog | 20 |
| Maximum number of XPath queries in Event Log | 100 |
| Maximum number of data flows | 10 |
| Maximum number of data streams | 10 |
| Maximum number of extensions | 10 |
| Maximum size of extension settings | 32 Kb |
| Maximum number of Log Analytics workspaces | 10 |
Log queries and language
General query limits
| Limit | Description |
|---|---|
| Query language | Azure Monitor uses the same Kusto query language as Azure Data Explorer. See Azure Monitor log query language differences for KQL language elements not supported in Azure Monitor. |
| Azure regions | Log queries can experience excessive overhead when data spans Log Analytics workspaces in multiple Azure regions. See Query limits for details. |
| Cross resource queries | Maximum number of Application Insights resources and Log Analytics workspaces in a single query limited to 100. Cross-resource query is not supported in View Designer. Cross-resource query in log alerts is supported in the new scheduledQueryRules API. See Cross-resource query limits for details. |
User query throttling
Azure Monitor has several throttling limits to protect against users sending an excessive number of queries. Such behavior can potentially overload the system backend resources and jeopardize service responsiveness. The following limits are designed to protect customers from interruptions and ensure consistent service level. The user throttling and limits are designed to impact only extreme usage scenario and should not be relevant for typical usage.
| Measure | Limit per user | Description |
|---|---|---|
| Concurrent queries | 5 | If there are already 5 queries running for the user, any new queries are placed in a per-user concurrency queue. When one of the running queries ends, the next query will be pulled from the queue and started. This does not include queries from alert rules. |
| Time in concurrency queue | 3 minutes | If a query sits in the queue for more than 3 minutes without being started, it will be terminated with an HTTP error response with code 429. |
| Total queries in concurrency queue | 200 | Once the number of queries in the queue reaches 200, any additional queries will by rejected with an HTTP error code 429. This number is in addition to the 5 queries that can be running simultaneously. |
| Query rate | 200 queries per 30 seconds | This is the overall rate that queries can be submitted by a single user to all workspaces. This limit applies to programmatic queries or queries initiated by visualization parts such as Azure dashboards and the Log Analytics workspace summary page. |
- Optimize your queries as described in Optimize log queries in Azure Monitor.
- Dashboards and workbooks can contain multiple queries in a single view that generate a burst of queries every time they load or refresh. Consider breaking them up into multiple views that load on demand.
- In Power BI, consider extracting only aggregated results rather than raw logs.
Log Analytics workspaces
Data collection volume and retention
| Tier | Limit per day | Data retention | Comment |
|---|---|---|---|
| Current Per GB pricing tier (introduced April 2018) |
No limit | 30 - 730 days | Data retention beyond 31 days is available for additional charges. Learn more about Azure Monitor pricing. |
| Legacy Free tiers (introduced April 2016) |
500 MB | 7 days | When your workspace reaches the 500 MB per day limit, data ingestion stops and resumes at the start of the next day. A day is based on UTC. Note that data collected by Azure Security Center is not included in this 500 MB per day limit and will continue to be collected above this limit. |
| Legacy Standalone Per GB tier (introduced April 2016) |
No limit | 30 to 730 days | Data retention beyond 31 days is available for additional charges. Learn more about Azure Monitor pricing. |
| Legacy Per Node (OMS) (introduced April 2016) |
No limit | 30 to 730 days | Data retention beyond 31 days is available for additional charges. Learn more about Azure Monitor pricing. |
| Legacy Standard tier | No limit | 30 days | Retention can't be adjusted |
| Legacy Premium tier | No limit | 365 days | Retention can't be adjusted |
Number of workspaces per subscription.
| Pricing tier | Workspace limit | Comments |
|---|---|---|
| Free tier | 10 | This limit can't be increased. |
| All other tiers | No limit | You're limited by the number of resources within a resource group and the number of resource groups per subscription. |
Azure portal
| Category | Limit | Comments |
|---|---|---|
| Maximum records returned by a log query | 30,000 | Reduce results using query scope, time range, and filters in the query. |
Data Collector API
| Category | Limit | Comments |
|---|---|---|
| Maximum size for a single post | 30 MB | Split larger volumes into multiple posts. |
| Maximum size for field values | 32 KB | Fields longer than 32 KB are truncated. |
Query API
| Category | Limit | Comments |
|---|---|---|
| Maximum records returned in a single query | 500,000 | |
| Maximum size of data returned | ~104 MB (~100 MiB) | |
| Maximum query running time | 10 minutes | See Timeouts for details. |
| Maximum request rate | 200 requests per 30 seconds per Azure AD user or client IP address | See Rate limits for details. |
Azure Monitor Logs connector
| Category | Limit | Comments |
|---|---|---|
| Max size of data | ~16.7 MB (~16 MiB) | Connector infrastructure dictates that limit is set lower than query API limit |
| Max number of records | 500,000 | |
| Max query timeout | 110 second | |
| Charts | Visualization in Logs page and the connector are using different charting libraries and some functionality isn't available in the connector currently. |
General workspace limits
| Category | Limit | Comments |
|---|---|---|
| Maximum columns in a table | 500 | |
| Maximum characters for column name | 500 |
Azure Monitor is a high scale data service that serves thousands of customers sending terabytes of data each month at a growing pace. The volume rate limit intends to isolate Azure Monitor customers from sudden ingestion spikes in multitenancy environment. A default ingestion volume rate threshold of 500 MB (compressed) is defined in workspaces, this is translated to approximately 6 GB/min uncompressed -- the actual size can vary between data types depending on the log length and its compression ratio. The volume rate limit applies to data ingested from Azure resources via Diagnostic settings. When volume rate limit is reached, a retry mechanism attempts to ingest the data 4 times in a period of 30 minutes and drop it if operation fails. It doesn't apply to data ingested from agents or Data Collector API.
When data sent to your workspace is at a volume rate higher than 80% of the threshold configured in your workspace, an event is sent to the Operation table in your workspace every 6 hours while the threshold continues to be exceeded. When ingested volume rate is higher than threshold, some data is dropped and an event is sent to the Operation table in your workspace every 6 hours while the threshold continues to be exceeded. If your ingestion volume rate continues to exceed the threshold or you are expecting to reach it sometime soon, you can request to increase it in by opening a support request.
See Monitor health of Log Analytics workspace in Azure Monitor to create alert rules to be proactively notified when you reach any ingestion limits.
Note
Depending on how long you've been using Log Analytics, you might have access to legacy pricing tiers. Learn more about Log Analytics legacy pricing tiers.
Application Insights
There are some limits on the number of metrics and events per application, that is, per instrumentation key. Limits depend on the pricing plan that you choose.
| Resource | Limit | Note |
|---|---|---|
| Total data per day | 100 GB | You can reduce data by setting a cap. If you need more data, you can increase the limit in the portal, up to 1,000 GB. For capacities greater than 1,000 GB, send email to AIDataCap@microsoft.com. |
| Throttling | 32,000 events/second | The limit is measured over a minute. |
| Data retention | 30-730 days | This resource is for Search, Analytics, and Metrics Explorer. |
| Availability multi-step test detailed results retention | 90 days | This resource provides detailed results of each step. |
| Maximum event size | 64,000 bytes | |
| Property and metric name length | 150 | See type schemas. |
| Property value string length | 8,192 | See type schemas. |
| Trace and exception message length | 32,768 | See type schemas. |
| Availability tests count per app | 100 | |
| Profiler data retention | 5 days | |
| Profiler data sent per day | 10 GB |
For more information, see About pricing and quotas in Application Insights.