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.

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. kagiyama yutaka 5,575 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
  2. Abhinaba Das 115 Reputation points Microsoft External Staff Moderator
    2026-09-27T22:44:20.7166667+00:00

    Hi @Andrew Sabin

    Thank you for providing the additional details.

    Based on the behavior and logs shared, I would not** recommend changing the SQL connection string or simply increasing the connection timeout as the first resolution. The strongest reproducible symptom is that, after the application remains idle for approximately 20–30 minutes, the next operation results in an HTTP **404 and the application navigates to the NotFound page. Refreshing the application then restores functionality.

    The connection string screenshot also shows an Azure SQL endpoint (*.database.windows.net). This format is valid for Azure SQL Database connectivity and, by itself, doesn't indicate a connection-string problem. Microsoft also documents Azure SQL database connectivity for Azure Static Web Apps scenarios.

    1.** Identify the request returning **404

    When the problem occurs, open Browser** Developer Tools (F12) > **Network, reproduce the failure, and locate the request returning 404.

    Check:

    • Request URL
    • Request method
    • Response body
    • Whether the request is for an application route or the backend API

    This is important because an HTTP 404 means that the requested route/resource wasn't found. If the failing request is the backend API, troubleshoot the API endpoint and its server-side logs rather than the Azure SQL connection itself.

    2.** Review Azure Static Web Apps **routing

    If the request is an application route, review staticwebapp.config.json, particularly the route and fallback configuration.

    Azure Static Web Apps uses this file to control routing, authentication/authorization rules, fallback routes, and HTTP response overrides.

    For a Blazor application that relies on client-side routing, ensure that the required fallback behavior is configured so that valid application routes aren't incorrectly handled as missing resources.

    3.** Check the backend/API **path

    Because the database access occurs through an API/backend, verify whether the API endpoint itself still works when the issue occurs.

    If the failed request is an API call:

    • Check the API/backend logs for the same timestamp.
    • Verify whether authentication/session state has expired.
    • Check whether the endpoint returned the 404 directly.
    • Verify that the route requested by the Blazor component matches the API route.
    • Check the underlying database operation only if the request successfully reaches the backend.

    This separates a routing/API issue from an actual database connectivity failure.

    4.** Don't rely on prerender=true as the **fix

    Changing the component to prerender=true isn't expected to resolve this type of idle-time 404 on its own.

    In Blazor, prerendering determines how interactive components are initially rendered before they become interactive. Microsoft also notes that prerendering is enabled by default for interactive components.

    Given that enabling prerendering didn't change the reported behavior, I wouldn't focus further troubleshooting on that setting.

    Conclusion

    Based on the currently available evidence, the recommended troubleshooting path is:

    Blazor** client → failing HTTP request → Static Web Apps route/API → backend → **database

    rather than assuming that the SQL connection string is causing the problem.

    The earlier SQL timeout should still be correlated with backend logs if it occurs again, but the repeatable 404** → NotFound → refresh restores **functionality behavior should be investigated at the application/API routing layer first.

    If anyone encounters the same issue, capturing the failed request from F12** > **Network is particularly useful because it immediately establishes which layer is returning the 404.

    Microsoft official documentation

    If the answer is helpful, please do click "Accept the answer” and Yes, this can be beneficial to other community members.

    Was this answer helpful?

    0 comments

  3. 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.