Azure SQL server DB is not pausing automatically even though there are no active connections.

Hi Gururaj Karthik,
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*

Please verify there are applications sessions or user sessions preventing the auto-pause:

SELECT session_id,
       host_name,
       program_name,
       client_interface_name,
       login_name,
       status,
       login_time,
       last_request_start_time,
       last_request_end_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_resource_governor_workload_groups AS wg
ON s.group_id = wg.group_id
WHERE s.session_id <> @@SPID
      AND
      (
      (
      wg.name like 'UserPrimaryGroup.DB%'
      AND
      TRY_CAST(RIGHT(wg.name, LEN(wg.name) - LEN('UserPrimaryGroup.DB') - 2) AS int) = DB_ID()
      )
      OR
      wg.name = 'DACGroup'
      );

Applications connected to the database like SQL Server Managment Studio (SSMS) can prevent the database to auto-pause and can wake up the database using Object Explorer on SSMS.

Other features like Full-Text Search in use on the database can prevent also the database to go to auto-pause.

You can use Query Performance Insights to see the query executed to the database, including things like backups (exports) that can prevent the database to auto-pause also.

Backups and restores can also prevent the database to auto-pause. Automated backups can be set to retention period of 1 using the portal (Backups option on the left panel), and that is the closest you can get to disable them. You cannot completely disable automated backups as it is required for Azure SQL to operate.

Finally these Azure SQL or Azure features can prevent auto-pause also:

• Threat Detection
• Azure SQL Auditing
• TDE (Transparent Data Encryption)
• Vulnerability Assessment
• Data Masking
• Data Discovery / Data Classification
• Auto-Tuning
• Database Copying
• SQL Data Sync

Hi Gururaj Karthik,
This behavior is usually expected with serverless databases in Azure SQL Database and typically means the database is not considered fully idle by the platform, even if no user activity is visible.

Auto-pause only happens when the database has zero activity for the entire auto-pause delay period. In most cases, something in the environment continues to keep the database “active.” The common reasons are background connections (like application connection pooling), monitoring or health checks, or small periodic queries that reset the inactivity timer. Even minimal activity is enough to prevent auto-pause.

Additionally, certain configurations such as geo-replication, failover groups, or other data synchronization features will completely prevent auto-pause from triggering.

Because of this, the database continues running and incurs compute charges. From a billing perspective, charges are expected if the database does not meet the pause conditions. Refunds are generally not applicable unless there is a confirmed platform issue.

To move forward, I recommend checking for any application or service that might be maintaining connections, reviewing enabled features, and validating the auto-pause delay setting.

If needed, I can help you identify exactly what is keeping the database active.

For a serverless Azure SQL Database that is not auto‑pausing, there are two separate concerns: fixing auto‑pause and handling unexpected costs.

1. Troubleshoot why auto‑pause is not occurring

Auto‑pause only works for General Purpose, serverless databases and only when all of the following are true for the entire auto‑pause delay period:

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

Additionally, certain features block auto‑pause and force the database to stay online (though they still allow auto‑scaling):

• Geo‑replication (active geo‑replication and failover groups)
• Long‑term backup retention (LTR)
• Sync database used in SQL Data Sync (hub and member DBs can auto‑pause; the sync DB cannot)
• DNS alias on the logical server
• Elastic Jobs when the serverless DB is used as the Job Database (target DBs can still auto‑pause)

Actions:

1. Confirm the database is General Purpose, serverless, and that auto‑pause is enabled with a non‑zero delay.
2. Check whether any of the blocking features above are enabled. If any are in use, auto‑pause must be disabled and the database will remain online.
3. If auto‑pause is enabled and blocking features are not in use, verify that no sessions are connected:
   • Connect with a client tool and run the documented query to list sessions.
   • After running the query, disconnect; leaving this connection open will itself prevent auto‑pause.
4. If the query shows sessions, those sessions are preventing auto‑pause. Close/kill them at the application or from the database.
5. If the query shows no sessions, there may have been brief connections during the auto‑pause delay window. Use Auditing for Azure SQL Database to inspect activity during that period.

Note: Auto‑pausing can also be temporarily blocked during some service updates; once the update completes, auto‑pause becomes allowed again.

2. Understand auto‑resume and hidden activity

Even if applications appear idle, many operations can auto‑resume a paused database and keep consuming vCore seconds, for example:

• Login attempts
• Threat detection, auditing, data masking, TDE state checks
• Vulnerability assessment scans
• Query Store configuration changes
• Performance recommendations and auto‑tuning
• Database copy/export operations
• SQL Data Sync operations
• Changing vCores or auto‑pause delay
• Some SSMS behaviors (older than 18.1 can resume all DBs on the server when opening a query window)

Monitoring or management tools performing any of these operations will resume the database. The first connection after a pause also resumes the DB and returns error 40613; clients with proper retry logic will reconnect and continue, consuming compute.

Auto‑pause/auto‑resume latency is typically:

• Auto‑resume: on the order of ~1 minute
• Auto‑pause: 1–10 minutes of inactivity (no sessions and 0 CPU)

3. Minimizing cost going forward

For serverless databases:

• Tune minimum vCores, maximum vCores, and auto‑pause delay to match actual usage.
• Ensure tools like SSMS, monitoring agents, and job systems disconnect when not needed; open sessions are the most common reason a DB does not auto‑pause.
• If using the Azure SQL Database free offer, consider enabling Auto‑pause the database until next month once free credits are exhausted, or allow billing beyond the free amount if continued usage is required.

4. Refunds and billing disputes

Community guidance for unexpected Azure charges is to open a billing support request. Billing support is free and handled by dedicated billing engineers. The forum and this assistant cannot access accounts or process refunds.

For large or unexpected Azure SQL charges, the documented path is:

• Create a new billing support request in the Azure portal so a billing engineer can review usage and determine refund eligibility.

If using the Azure SQL Database free offer and the database continued to run after free limits were reached, check whether the configuration allowed billing beyond the free amount. If the option Auto-pause the database until next month was not selected, usage beyond the free quota is billable.

Whether Azure will refund depends on billing support’s investigation and policies; this cannot be determined here.

References:

• Serverless compute tier for Azure SQL Database
• Connect to an Azure SQL database
• Azure SQL Database free offer FAQ
• Can't find what is preventing auto-pause from working - Microsoft Q&A
• Fraud Charges - Microsoft Q&A