Azure Sql Database fails to consistently pause even after long periods of inactivity

Question

Azure Serverless database is set to auto-pause after 15 minutes of inactivity. DB fails to consistently pause even after long periods of inactivity. Intermittent messages about restart, but pause messages are very inconsistent. Status "online" is verified on the Azure Overview page.

Answer 1

Hi John,

Have you connected using SSMS and queried to see if there are any sessions? This will often show a session that is keeping it from pausing.

For example, if you disable T-SQL Intellisense and run below query from Auto-pause troubleshooting, does it show any sessions or is it empty result set? If you still have T-SQL Intellisense enabled it will show session for that, but there shouldn't be any others.

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'
      );

Please click Accept Answer if the above was helpful.

Thanks.

-TP

Answer 2

Another possibility to find out what is going on is to set up an extended-events sessions that captures the events rpc_completed and sql_batch_completed.

Answer 3

Hi John Grady,

Azure SQL Database Serverless auto-pause only happens when the database has no active user connections and no user activity for the full auto-pause delay that you configured. Even very small or infrequent activity is enough to reset the idle timer, which is why the pause behavior can appear inconsistent.

In practice, the most common reason a serverless database stays Online is that something is still connecting to it. This includes idle connections held open by applications, background health-check queries (for example SELECT 1), monitoring agents, Power BI refreshes, automation jobs, or connection pools that do not fully close sessions. Any of these count as activity and prevent auto-pause.

Auto-pause timing is also not exact. Even with a short delay configured, the database may pause a little later depending on internal scheduling. Additionally, during Azure maintenance or compute transitions, the platform can temporarily delay pausing. This behavior is expected and does not indicate a fault.

To see what is preventing the pause, you can check active sessions directly in the database:

SELECT session_id, login_name, host_name, program_name
FROM sys.dm_exec_sessions
WHERE is_user_process = 1;

You can also review pause and resume telemetry in the Azure Portal under SQL Database → Monitoring → Metrics / Diagnostic logs. Metrics such as sql_db_pause_blocking_reason and sql_db_resumed show whether a user connection, background query, or platform activity blocked or triggered a pause or resume.

To make auto-pause work more consistently, ensure all applications close connections properly, reduce the frequency of health checks or background queries, review connection pool settings, and consider increasing the auto-pause delay if light activity is expected during idle periods.

Helpful References:
https://learn.microsoft.com/en-us/azure/azure-sql/database/serverless-tier-overview?view=azuresql&tabs=general-purpose
https://learn.microsoft.com/en-us/azure/azure-sql/database/serverless-tier-overview?view=azuresql&tabs=general-purpose#auto-pause-delay
https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-exec-sessions-transact-sql?view=sql-server-ver17
https://techcommunity.microsoft.com/blog/azuresqlblog/identify-causes-of-auto-resuming-serverless-workloads-in-azure-sql-database/4452741

Hope this helps please let us know if you have any questions and concerns.