Share via

Serverless database not pausing - whats keeping it awake

Paul Hart 45 Reputation points
2026-03-27T14:35:57.36+00:00

Hi,

I have a few serverless databases, all of which are set to pause after 1 hours inactivity. Every now and again one decides to stop pausing even after days of no user activity.

I say no user activity - I can see from the Azure Overview there is a tiny amount of activity

I can see from Monitoring Metrics something is connected

And I can see from the following query something is connected

SELECT database_name, start_time, end_time, success_count, total_failure_count, connection_failure_count

FROM sys.database_connection_stats

WHERE start_time>='2026-03-23 12:00:00' and end_time<='2027-03-30 12:00:00'

ORDER BY start_time ASC;

How do I work out what this is? Can I get an IP Address or anything to help me identify the source?

I'm pretty new to this. Google has helped me get this far so if possible please be description with any instructions

Thanks

Paul

Azure SQL Database
0 comments
Answer accepted by question author
  1. SAI JAGADEESH KUDIPUDI 1,600 Reputation points Microsoft External Staff Moderator
    2026-03-27T17:50:39.2966667+00:00

    Hi Paul Hart,
    The database is not pausing because at least one connection is still active, which resets the auto-pause timer even if there is no visible user activity.

    Run the below query to identify exactly what is keeping it awake, including application name and client IP:

    SELECT 
  s.session_id,
  s.login_name,
  s.host_name,
  s.program_name,
  c.client_net_address
FROM sys.dm_exec_sessions s
JOIN sys.dm_exec_connections c 
  ON s.session_id = c.session_id
WHERE s.session_id <> @@SPID
  AND s.is_user_process = 1;

    Check program_name and client_net_address to find the source (SSMS, app, monitoring tool, etc.) and stop that connection. You can also confirm triggers from Azure Portal → Monitor → Activity Log by filtering “Resume Database” and checking the caller.

    Once all sessions drop to zero, the serverless database will auto-pause as expected.

    Reference Link:
    https://learn.microsoft.com/azure/azure-sql/database/serverless-tier-overview#auto-pause

    Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.

    Please do not forget to "Accept Answer" and "up-vote" wherever the information provided helps you, as this can be beneficial to other community members.

Answer accepted by question author
  1. TP 155.2K Reputation points Volunteer Moderator
    2026-03-27T17:01:23.0566667+00:00

    Hi Paul,

    As a start, please use SSMS to connect to the database that hasn't paused for long time, and execute below command:

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

    In the output you should see more helpful information about the sessions like host, program, user name, when they logged in, etc. In some cases you may see sessions from yourself (e.g. SSMS from your PC) while you are troubleshooting, so keep that in mind.

    Above is from the Auto-pause troubleshooting documentation.

    Please click Accept Answer and upvote if the above was useful.

    Thanks.

    -TP

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-03-27T14:36:18.0366667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Auto-pausing is blocked whenever there are active sessions or certain features that keep the database online. The tiny, periodic activity seen in metrics and in sys.database_connection_stats indicates something is still connecting, which is enough to prevent the database from becoming idle long enough to pause.

    Key points from the platform behavior:

    1. What prevents auto-pause
      Auto-pausing requires:
      • Number of sessions = 0, and
      • CPU = 0 for user workload during the entire auto-pause delay.
      In addition, if any of these features are in use, auto-pausing must be disabled and the database will stay online:
      • Geo-replication (active geo-replication or failover groups)
      • Long-term backup retention (LTR)
      • Sync database for SQL Data Sync
      • DNS alias on the logical server
      • Elastic Jobs when the database is used as the Job Database
      Any monitoring, management, or security operation that logs in or inspects the database can also auto-resume it.
    2. Why sys.database_connection_stats shows activity
      sys.database_connection_stats aggregates connectivity events (successful and failed logins) in 5‑minute buckets. Any nonzero success_count in a time window means something successfully connected in that interval, which is enough to:
      • Resume a paused database, or
      • Reset the auto-pause idle timer.
      This DMV does not expose IP addresses; it only shows counts per database and time window.
    3. How to identify what is waking the database
      Use platform logs rather than sys.database_connection_stats alone:
      • Azure Monitor Activity Log:
        For serverless databases, auto-resume events appear as Resume Databases operations. The Caller field in the JSON of the Started/Succeeded events shows what triggered the resume (for example, a user principal, an application, or a Microsoft service). This is the primary way to see who/what is waking the database.
      • Auditing (if enabled):
        Auditing for Azure SQL Database can show login attempts and queries, including the principal name and sometimes the client information. This helps correlate which app or user is connecting during the periods where sys.database_connection_stats shows activity.
      • Check for blocking features:
        Confirm that none of the following are configured on that database or its server, because they require auto-pause to be disabled:
        • Active geo-replication or failover groups
        • LTR backups
        • SQL Data Sync sync database role
        • DNS alias on the logical server
        • Elastic Jobs using this database as the Job Database
    4. Additional checks when auto-pause should work but doesn’t
      • Query for active sessions when the database is expected to be idle. If any sessions appear, they are preventing auto-pause. After checking, disconnect the session used for the query so it does not itself keep the database online.
      • If the result set is empty but the database still does not pause, use auditing to look for short-lived connections during the auto-pause delay window.
    5. IP address specifically
      The provided context does not expose a direct way to obtain client IP addresses from sys.database_connection_stats. Identification is done via:
      • Activity Log Caller for resume events, and
      • Auditing records for login activity and principals.

    Using Activity Log plus auditing around the times where sys.database_connection_stats shows success_count > 0 will allow correlation of which identity or process is keeping the database awake.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.