Issues with Blazor Web App Connecting To SQL Server Consistently

Andrew Sabin 80 Reputation points
2026-08-24T22:13:32.8866667+00:00

Hello Microsoft Support,

With my Blazor Web App hosted as an Azure Static Web app, I have been having issues with accessing certain information through different pages that are stored on a SQL server after opening a tab accessing my Web App and keeping it idle for around 20 to 30 minutes.

Here is the connection string that I am using with my Azure Static Web app to connect to the specific database:

Server=tcp:<DataBaseName>,<PortNumber>;Initial Catalog=<ServerName>;Persist Security Info=False;User ID=<UserName>;Password=<Password>;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=60;

Would this be an issue with my web application or the connection string that I am using? I can provide information from the Program.cs file if you need me to.

Thank you very much for your time and help,

Andrew Sabin

Azure Static Web Apps
Azure Static Web Apps

An Azure service that provides streamlined full-stack web app development.


2 answers

Sort by: Most helpful
  1. kagiyama yutaka 5,165 Reputation points
    2026-08-24T22:51:54.2033333+00:00

    I think the behavior you saw aligns with Azure SQL ending idle sessions around 20–30 minutes. Azure Static Web Apps run Blazor only on the client and cannot keep any SQL connection, so direct access to SQL becomes unstable after idle periods. The stable setup is to move the DB access into a small Azure Functions API and call it from the pages.

    This isn’t a connection‑string issue — it simply matches Azure SQL’s idle‑session behavior. 

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments

  2. AI answer

    2026-08-24T22:13:52.27+00:00

    This is most likely a connection-idle issue rather than a Blazor page issue.

    Azure SQL Database can terminate idle connections after about 30 minutes when the connection is idle at the TDS/query layer, even if TCP keepalive is present. That matches the pattern described: the app works, sits idle for 20–30 minutes, then fails on the next database access.

    The connection string is not the main problem based on the idle timing alone. The important parts already align with recommended settings:

    • Use the fully qualified Azure SQL server name and port 1433
    • Keep Encrypt=True
    • Keep TrustServerCertificate=False
    • Use a connection timeout of at least 30 seconds

    Recommended checks and fixes:

    1. Verify the server name format in the connection string.
      • For Azure SQL Database, use the fully qualified server name in this form: Server=tcp:<database-server-name>.database.windows.net,1433;
      • If the current Server=tcp:<DataBaseName>,<PortNumber>; value is not the Azure SQL fully qualified name, correct it.
    2. Confirm the database name placement.
      • Initial Catalog should be the database name.
      • The server name belongs in the Server= portion.
    3. Add retry logic in the app.
      • Retry logic is strongly recommended for Azure SQL client applications so the app can reconnect after transient failures.
      • The recommended first retry delay is 5 seconds, then increase delays exponentially up to 60 seconds.
    4. Check for stale DNS or hosts-file overrides.
      • If failures happen only on certain networks, remove any hosts-file, static CNAME, or other DNS override for the Azure SQL FQDN, then flush DNS and retest.
    5. For Azure Static Web Apps, verify database access prerequisites.
      • The database firewall must allow network access from Azure resources for Static Web Apps workers.
      • Allowing specific Static Web Apps IP addresses is not supported.
      • If Managed Identity authentication is used, the Static Web App managed identity must be granted access to the database.
    6. If using the JDBC driver anywhere in the stack, review idle connection handling.
      • Azure SQL documentation notes that idle connections can be dropped by network devices or by the Azure SQL Gateway after 30 minutes of no active query.
      • Using the Redirect connection policy is one documented way to avoid gateway termination of idle connections.

    A corrected Azure SQL connection string shape would be:

    Server=tcp:<database-server-name>.database.windows.net,1433;Initial Catalog=<database-name>;Encrypt=True;TrustServerCertificate=False;Connection Timeout=60;
    

    A better long-term option is passwordless authentication instead of storing SQL username and password in the connection string. For Azure SQL, the recommended pattern is:

    Server=tcp:<database-server-name>.database.windows.net,1433;Initial Catalog=<database-name>;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;Authentication="Active Directory Default";
    

    If the current issue is specifically “fails after being idle,” the first practical fix is to implement retry logic and verify the server/database values in the connection string.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

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.