How can I avoid cold-start timeouts with a serverless Azure database?

September 9, 2026 4 answers
Asked by MellowPine47
I'm testing a mobile app that hasn't been released yet, and I'm currently the only person using it. When I open it after the database has been idle for about a day, the first connection sometimes fails with what appears to be a timeout. The database is on an inexpensive serverless plan, so I suspect it is paused and needs time to start again. Is there a way to periodically wake it up or otherwise reduce the first-request delay? I'd prefer not to increase my Azure bill.

Answers

CrispOrbit8
You can run a small query every couple of hours as a health check, or disable the automatic pause feature. However, keeping the database active means youโ€™ll be charged for compute, so the periodic-query approach defeats much of the cost benefit of serverless.
Reply to this answer
SilverKite61
The cold start is the trade-off for serverless billing. If you keep it running continuously, the monthly compute cost can increase substantially, especially on a free or limited-use tier. For testing, it may be better to handle the first connection with a retry and a user-friendly loading message.
Reply to this answer
QuietHarbor23
A scheduled VM or script could periodically connect and run a query, with retry logic for occasional startup delays. But there isnโ€™t really a way to eliminate the cold start while keeping the database paused and free.
Reply to this answer
BrightCedar5
If you need an always-available relational database, consider moving to the cheapest provisioned or DTU-based tier. It stays online and can be relatively inexpensive, though the smallest options have limited performance and storage. For a small test application, a low-tier plan may cost less than trying to prevent serverless auto-pausing.

MellowPine47: That sounds like the most practical option. Iโ€™ll look into switching the database to a small provisioned tier and compare the monthly cost.

Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions