Building a Custom Health Check for Azure SQL in ASP.NET Core

Modern distributed applications rely on rapid feedback to know when a dependency is failing, and that requirement is especially sharp for teams running workloads on Microsoft Azure. Whether the system is hosted on Azure App Service in Sydney, deployed to AKS clusters in Melbourne, or sitting behind an Application Gateway in Brisbane, knowing whether the data tier is reachable can mean the difference between a quick self-healing restart and a customer-visible outage. ASP.NET Core ships with a flexible diagnostics layer called Microsoft.Extensions.Diagnostics.HealthChecks, and it provides a clean extension point for plugging in domain-specific probes against external services. That extension point is the most practical place to add a tailored Azure SQL Database check, because the built-in helpers do not capture every nuance of a managed cloud database.

This article walks through the process of designing, coding, registering, and exposing a custom health check that targets Azure SQL Database, including the probe logic, transient error handling, and the response writer that turns raw results into something useful for dashboards. Along the way the discussion stays grounded in realities familiar to Australian engineering teams — data residency under the Privacy Act, the Essential Eight maturity model promoted by the Australian Cyber Security Centre, and the way Microsoft Azure Australia regions (Australia East and Australia Southeast) are commonly paired for disaster recovery. The end goal is a small, well-tested component that integrates cleanly with Kubernetes liveness and readiness probes, Azure Monitor, and any external uptime monitor.

The Health Checks Stack in ASP.NET Core

The diagnostics namespace was introduced in .NET Core 2.2 and has matured significantly since then. At its core sits the IHealthCheck interface, which exposes a single async method that returns a HealthCheckResult. The result carries a HealthStatus enum value (Healthy, Degraded, or Unhealthy), an optional description, and an exception when something has gone wrong. The framework aggregates the results from every registered check, applies any configured failure status, and writes the aggregated state to the configured endpoint.

Several extension methods make common scenarios quick to wire up. AddDbContextCheck covers Entity Framework Core contexts, AddSqlServer is meant for raw SQL Server instances, and AddAzureBlobStorage, AddRedis, and AddRabbitMQ cover other managed services. AddSqlServer under the hood simply opens a connection and executes SELECT 1, which is enough as a smoke test but does not account for Azure SQL-specific concerns such as elastic pool saturation, serverless pause behaviour, or transparent data encryption state. That gap is the reason most teams operating production workloads in Australia end up rolling their own implementation, then registering it alongside the built-in checks.

Why Azure SQL Asks for a Bespoke Probe

Azure SQL Database is not the same product as a self-managed SQL Server, even though the wire protocol is identical. Each logical server sits behind a regional gateway, pools resources inside an elastic pool or a serverless compute tier, and exposes throttling logic that can return error codes such as 10928 or 10929 when limits are hit. A simple SELECT 1 succeeds even when the database is in a paused state on a serverless tier or when the elastic pool has no available DTUs, which is why treating that query as the sole indicator of health can produce false positives.

Local context matters too. Australian regulations such as the Notifiable Data Breaches scheme under the Privacy Act 1988 push engineering teams toward observability that records not just whether a database is up, but whether recent queries are completing inside an acceptable window. A team running a payments service hosted out of Australia East and failing over to Australia Southeast for a Sydney–Melbourne active-active design needs its health probe to confirm round-trip latency, not just connectivity. Encoding that knowledge in a custom IHealthCheck is the cleanest way to surface the right signal to the platform.

Implementing the IHealthCheck Class

The first step is a class that implements IHealthCheck. The constructor receives the configuration and any injected collaborators, while CheckHealthAsync carries the probe logic. The skeleton typically looks like a small class registered through dependency injection, accepting an IConfiguration root to read the connection string and an optional ILogger for structured logging.

public sealed class AzureSqlHealthCheck : IHealthCheck
{
    private readonly string _connectionString;
    private readonly TimeSpan _commandTimeout;
    private readonly ILogger<AzureSqlHealthCheck> _logger;

    public AzureSqlHealthCheck(IConfiguration configuration, ILogger<AzureSqlHealthCheck> logger)
    {
        _connectionString = configuration.GetConnectionString("AzureSql")
            ?? throw new InvalidOperationException("AzureSql connection string missing.");
        _commandTimeout = TimeSpan.FromSeconds(
            configuration.GetValue<int?>("HealthChecks:AzureSql:CommandTimeoutSeconds") ?? 3);
        _logger = logger;
    }

    public async Task<HealthCheckResult> CheckHealthAsync(
        HealthCheckContext context, CancellationToken cancellationToken = default)
    {
        try
        {
            await using var connection = new SqlConnection(_connectionString);
            await connection.OpenAsync(cancellationToken);
            await using var command = connection.CreateCommand();
            command.CommandText = "SELECT 1";
            command.CommandTimeout = (int)_commandTimeout.TotalSeconds;
            await command.ExecuteScalarAsync(cancellationToken);
            return HealthCheckResult.Healthy("Azure SQL reachable.");
        }
        catch (SqlException ex) when (IsTransient(ex))
        {
            _logger.LogWarning(ex, "Transient Azure SQL failure during health probe.");
            return HealthCheckResult.Degraded("Azure SQL transient failure.", ex);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Azure SQL probe failed.");
            return HealthCheckResult.Unhealthy("Azure SQL probe failed.", ex);
        }
    }

    private static bool IsTransient(SqlException ex) =>
        SqlClientRetryLogic.IsTransient(ex) || ex.Number is 10928 or 10929 or 4060;
}

The probe deliberately distinguishes between Degraded and Unhealthy so that Kubernetes liveness probes are not restarted for transient hiccups. Structured logging through ILogger means the events flow naturally into Application Insights and on to dashboards reviewed by Sydney-based SREs during the morning AEST handover. IsTransient catches throttling errors, while general exceptions — including login failures, network resets, and certificate validation issues — are treated as Unhealthy.

Handling Transient Errors and Measuring Latency

A custom probe should not stop at connectivity. Capturing the elapsed time against the database is a cheap way to detect slowdowns that may indicate an overloaded elastic pool. Wrapping the call in a Stopwatch and attaching the elapsed milliseconds as data on the HealthCheckResult helps dashboards chart response time alongside availability. The trick is to keep the probe cheap enough that thousands of instances polling every few seconds do not pressure the gateway.

Polly is the standard tool for handling transient errors around the probe, and Microsoft.Data.SqlClient ships with a configurable retry provider that uses similar rules. Wrapping the OpenAsync and ExecuteScalarAsync calls inside an AsyncRetryPolicy with a couple of attempts and an exponential back-off protects the probe from being misled by a single packet drop, while still completing inside the liveness interval. For Australian deployments crossing regions to a secondary in Australia Southeast, setting the connection's Connect Timeout explicitly and bounding it to roughly two seconds keeps the entire probe inside a five-second budget.

Registering, Tagging, and Exposing the Endpoint

With the check implemented, the next step is registration inside Program.cs. The AddHealthChecks().AddCheck<>() call wires the type into the DI container, while tags separate liveness from readiness. Kubernetes typically polls /healthz/live for restart decisions and /healthz/ready for traffic gating, so the registration maps two endpoints with different tag filters.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHealthChecks()
    .AddCheck<AzureSqlHealthCheck>(
        name: "azure-sql",
        failureStatus: HealthStatus.Unhealthy,
        tags: new[] { "db", "ready", "sql" });

builder.Services.AddSingleton<AzureSqlHealthCheck>();

var app = builder.Build();

app.MapHealthChecks("/healthz/live", new HealthCheckOptions
{
    Predicate = _ => false
});

app.MapHealthChecks("/healthz/ready", new HealthCheckOptions
{
    Predicate = r => r.Tags.Contains("ready"),
    ResponseWriter = HealthResponseWriter.WriteJsonAsync
});

A custom response writer that returns JSON, including the per-check status, duration, and tags, makes the endpoint useful for monitoring tools. Tools such as Pingdom, UptimeRobot, or an internal status page hosted on Azure Static Web Apps in Australia can parse the JSON and raise alerts when an individual dependency is degraded.

Observability, Alerting, and Compliance

Health endpoints only earn their keep when the data they emit reaches somewhere useful. Piping ILogger output into Application Insights gives engineers in Melbourne and Sydney a live view of probe duration, exception rates, and the times at which degradation events occur. Azure Monitor alert rules can then page an on-call engineer through SMS or a local Teams channel when three consecutive probes report Unhealthy, or when the rolling average of probe duration crosses a threshold that suggests an elastic pool is saturating.

Compliance considerations sit alongside observability. The Australian Cyber Security Centre's Essential Eight maturity model encourages application control, patching, and configuration baselines; a custom health check fits naturally as part of the configuration baseline for production web apps. The Notifiable Data Breaches scheme, meanwhile, makes it important that any probe failure that risks data exposure is logged with enough context for the security team to assess whether an assessment statement is required. Storing the probe outcomes for at least 30 days in a Log Analytics workspace in Australia East keeps the audit trail local, satisfying data residency expectations common in government and banking workloads.

Built-in vs Custom: A Quick Comparison

Pre-Deployment Checklist

• Verify the connection string uses Encrypt=True and TrustServerCertificate=False, in line with ACSC guidance for production data tiers.
• Confirm the firewall rules on the Azure SQL logical server allow the App Service outbound IP range or the private endpoint subnet.
• Place the database in the Australia East region and replicate to Australia Southeast for cross-region resilience.
• Set CommandTimeout to three seconds or fewer to keep the probe inside a Kubernetes liveness window.

Tuning Tips for the Probe

• Cache the SqlConnection instance across probes if your library allows it; otherwise open and dispose per call.
• Add a counter metric for probe duration and emit it through Azure Monitor metrics.
• Use a dedicated lightweight login for the probe account with the minimum permissions required for SELECT.
• Re-test the probe locally by throttling the elastic pool to confirm that Degraded states fire correctly.