Database 'SalesDB' on server 'sqlsvr01' is currently paused. Please retry the connection later. – Auto‑pause timer behavior
0 reputation · 20 Nov 2022, 23:23 UTC
0 reputation · 20 Nov 2022, 23:23 UTC
Determine whether the Azure SQL Database serverless auto‑pause timer resets on each successful query or only on the first activity after a paused state, to predict latency for low‑traffic, sporadic workloads.
The auto‑pause delay is configurable (e.g., 60 minutes to 1 week) but documentation does not specify if the timer is refreshed by every query or only by the first query after a pause. This ambiguity leads to unpredictable compute resume latency for applications that issue infrequent requests.
Questions:
The auto-pause timer resets after every successful query or connection, not only after the first activity following a pause. The configured delay (e.g., 60 minutes) represents a continuous inactivity window—any user query restarts that window.
| Query Interval | Relative to Auto-Pause Delay | Observed Latency |
|---|---|---|
| Shorter than delay | e.g., queries every 30 min with 60-min delay | Database stays warm; no resume penalty. |
| Longer than delay | e.g., queries every 2 hours with 60-min delay | Each query after a pause pays the cold-start resume latency. |
| Near the delay boundary | e.g., queries every 55–65 min with 60-min delay | Unpredictable: some requests hit a warm DB, others trigger a pause/resume cycle. |
What is the exact auto-pause delay configured for SalesDB on sqlsvr01? If it is set to the minimum (1 hour) and your workload issues queries every 70 minutes, you will see a resume penalty on every other request. Increasing the delay (up to 7 days) or disabling auto-pause eliminates the latency spikes at the cost of higher compute billing during idle periods.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.