Why does my Azure SQL Database with auto-pause enabled show recurring CPU spikes every 5 minutes overnight and is it generating billable compute time?

Question

I have two Azure SQL Databases across two separate development stages: Dev 1 (serverless tier, auto-pause enabled) and Dev 2 (auto-pause disabled). Both databases are configured identically apart from the auto-pause setting. Both receive traffic from separate but equivalently configured Azure Web Apps, Elastic Job Agents, and Azure Batch Accounts running the same workloads and schedules. These are two sequential development environments used before changes are promoted to production.

On Dev 1, I am seeing recurring CPU spikes on the SQL instance CPU percent metric every 5 minutes exactly between 3:00 AM and 5:00 AM CDT (08:00 to 10:00 UTC). Dev 2 shows no such pattern during the same window, despite receiving the same application traffic and queries. Because both environments receive identical traffic from the same types of systems, the difference in behavior is not attributable to Dev 2 having less activity or fewer connections. The only meaningful configuration difference is the auto-pause setting.

Observed behavior (Dev 1: auto-pause enabled)

The Azure Monitor metrics chart below shows the 5-minute interval spikes on SQL instance CPU percent reaching 8-13% between 4:00 AM and 4:50 AM CDT (09:00 to 09:50 UTC) on 2026-04-16, while CPU percentage, Data IO, Log IO, and Workers all remain flat at 0%.

Investigation summary

To identify the cause I queried AzureMetrics in Log Analytics scoped to the spike window. This confirmed 12 consecutive spikes at exactly 5-minute intervals with SQL instance CPU reaching 9-13%, matching the chart. The same query against Dev 2 returned nothing above 2%.

I then checked AzureDiagnostics for SQLSecurityAuditEvents and Connections during the same window. No results were returned, confirming no user or application connections were made to Dev 1 during the entire 3:00 AM to 5:00 AM CDT window.

Querying sys.query_store_runtime_stats on Dev 1 for the same window returned only two internal queries: a SELECT against an internal backup_metadata_store table (query_id 177931) and a poll of sys.dm_db_resource_stats (query_id 112304). Both had object_id = 0, confirming they are Azure platform queries and not user-defined code or scheduled jobs. The same Query Store query against Dev 2 returned no results.

Finally, querying AzureDiagnostics for QueryStoreRuntimeStatistics during the spike window confirmed that query_id 177931 and query_id 112304 were the only queries active at every spike interval, with no other activity present.

Comparison summary

Observation	Dev 1 (auto-pause on)	Dev 2 (auto-pause off)
5-min CPU spikes (3:00 to 5:00 AM CDT)	Yes; 12 spikes at 9-13%	No
5-min CPU spikes (3:00 to 5:00 AM CDT)	Yes; 12 spikes at 9-13%	No
backup_metadata_store queries	Yes (query_id 177931)	None
dm_db_resource_stats poll	Yes (query_id 112304)	None
User or app connections during window	None	None
object_id on all Query Store rows	0 (internal)	N/A

Questions

1. Is this expected Azure platform behavior; specifically, does Azure internally resume an auto-paused serverless database on a ~5-minute interval between 3:00 AM and 5:00 AM CDT (08:00 to 10:00 UTC) to perform backup chain verification via backup_metadata_store queries?
2. Do these internal Azure-initiated resume events generate billable compute time against the serverless database, even though no user or application connections are present?
3. Is there any configuration change that would reduce the frequency of these internal resume events, short of disabling auto-pause entirely?

Answer 1

Hello **Daniel-4204

**Azure serverless database bills for the amount of compute used per second. The serverless compute tier also automatically pauses databases during inactive periods when only storage is billed and automatically resumes databases when activity returns.

The configuration of these parameters shapes the database performance experience and compute cost.

The auto-pause delay is a configurable parameter that defines the period of time the database must be inactive before it is automatically paused. The database is automatically resumed when the next login or other activity occurs. Alternatively, automatic pausing can be disabled.

The cost for a serverless database is the summation of the compute cost and storage cost. The storage cost is determined in the same way as in the provisioned compute tier.

• When compute usage is between the minimum and maximum limits configured, the compute cost is based on vCore and memory used.
• When compute usage is below the minimum limits configured, the compute cost is based on the minimum vCores and minimum memory configured.
• When the database is paused, the compute cost is zero and only storage costs are incurred.

Auto-pausing is triggered if all of the following conditions are true during the auto-pause delay:

• Number of sessions = 0
• CPU = 0 for user workload running in the user resource pool

The following features do not support auto-pausing, but do support auto-scaling. If any of the following features are used, then auto-pausing must be disabled and the database remains online regardless of the duration of database inactivity:

• Geo-replication (active geo-replication and failover groups).
• Long-term backup retention (LTR).
• The sync database used in SQL Data Sync. Unlike sync databases, hub and member databases support auto-pausing.
• DNS alias created for the logical server containing a serverless database.
• Elastic Jobs, Auto-pause enabled serverless database is not supported as a Job Database. Serverless databases targeted by elastic jobs do support auto-pausing. Job connections resume a database.

The presence of open sessions, with or without concurrent CPU utilization in the user resource pool, is the most common reason for a serverless database to not auto-pause as expected.

https://learn.microsoft.com/en-us/azure/azure-sql/database/serverless-tier-overview?view=azuresql&tabs=general-purpose

Answer 2

Hi Daniel-4204,

In the serverless tier, the database automatically pauses when idle and resumes when any activity occurs. This activity is not limited to user connections; it also includes internal platform operations such as automated backups, backup chain maintenance, and service-level monitoring. Microsoft documentation confirms that these operations are fully managed by the service and their timing is determined by the platform, not user-configurable:
https://learn.microsoft.com/en-us/azure/azure-sql/database/automated-backups-overview

The queries you identified (for example against internal metadata and DMVs, with object_id = 0) indicate Azure-initiated internal activity, not application workload. The reason you only see CPU spikes in Dev 1 is because auto-pause is enabled there. When the database is paused, any internal operation causes a resume event, which briefly brings the database online and results in visible CPU usage. In Dev 2, the database is always online, so the same internal work happens but does not appear as periodic spikes.

Regarding billing, Azure SQL serverless compute is charged per second while the database is online, and not charged while paused. This means that even if the resume is triggered by internal platform activity, the time during which the database is active is still considered billable compute time:
https://learn.microsoft.com/en-us/azure/azure-sql/database/serverless-tier-overview?view=azuresql&tabs=general-purpose

Adjusting the auto-pause delay or disabling auto-pause are the only ways to reduce frequent resume cycles, but the internal maintenance behavior itself cannot be controlled. However, the behavior you are observing is consistent with internal service operations periodically waking a paused database.

If you would like, we can further correlate these timestamps for deeper validation of this pattern in your environment.