Edit

Automatic internal connectivity tests for Azure SQL Managed Instance

Applies to: Azure SQL Managed Instance

This article describes the automatic internal connectivity tests that run on Azure SQL Managed Instance to monitor service reliability and accelerate issue detection.

These tests are fully automated and require no action from you. Proactive monitoring of internal network connections allows Microsoft to quickly identify potential issues and maintain stable end-to-end connectivity.

Connectivity tests run from a pair of internal IP addresses from the subnet range that hosts the SQL managed instance. Tests don't require any external inbound or outbound connectivity. Additional IP addresses are reserved for connectivity tests, and traces might appear in observability logs.

Beginning May 2026, connectivity tests run at regular intervals on all SQL managed instances.

Benefits

Automatic internal connectivity tests provide the following benefits:

  • Diagnose internal service and network availability issues.
  • Accelerate issue discovery and reduce mitigation time.
  • Improve visibility into the internal networking state of SQL Managed Instance.

Test results are used internally and don't reflect in Service Health or Resource Health.

Operational impact

Internal connectivity tests have the following operational impact:

  • Two extra IP addresses are provisioned for each VM group, increasing the IP address requirement from six to eight. For more information, see Determine subnet size and range.
  • Tests run every 10 seconds and have a negligible performance impact on network throughput and service performance.
  • New subnets created for SQL managed instances automatically reserve the extra IP addresses required for connectivity tests.
  • In existing subnets with SQL managed instances, the tests reserve extra IP addresses only if the subnet has enough free IP addresses to support the extra IP addresses required by the tests. If an existing subnet doesn't have enough free IP addresses, the tests don't run.

Security considerations

The following security principles guide the design of internal connectivity tests:

  • Tests are scoped to a single SQL managed instance and run inside its delegated virtual network and subnet.
  • Connectivity tests can't access the contents of any database.
  • Test results contain no customer data beyond the instance name.
  • Only Microsoft engineers can access the results.
  • Audit systems might record failed login attempts generated by the tests. For more information about how to identify these entries, see Observing failed logins caused by end-to-end tests.

Tests performed

The following connectivity tests run automatically:

Test Description
Load balancer connectivity Validates connectivity to the internal load balancer.
Internal DNS name resolution Verifies that internal DNS names resolve correctly.
Azure infrastructure dependency availability Checks availability of Azure infrastructure dependencies.
End-to-end in-subnet connectivity to the instance Validates the full connectivity pathway to Azure SQL Managed Instance by attempting a login with a known-to-fail credential (AzureSQLConnectivityChecker).

Observe failed logins caused by end-to-end tests

The end-to-end connectivity test intentionally performs a failed login to validate the full connectivity pathway. The test uses the AzureSQLConnectivityChecker login, which doesn't exist, and expects Azure SQL Managed Instance to return error 18456. This error validates that the entire network path to SQL Managed Instance is functional.

SQL observability tools can detect these failed logins. Use the following signatures to identify connectivity test entries and distinguish them from genuine failed login attempts.

The following observability tools detect failed sign-ins:

Audit logs

When you enable FAILED_LOGIN_GROUP, audit events appear approximately every 10 seconds in AzureDiagnostics:

Column Value
Category SQLSecurityAuditEvents
ResourceType MANAGEDINSTANCES
action_id_s LGIF
server_principal_name_s AzureSQLConnectivityChecker
client_ip_s IP address within the subnet range

Extended Events

Extended Event sessions that capture sqlserver.error_reported where error_number = 18456 and severity = 14 show the following attributes:

Attribute Value
category LOGON
error_number 18456
severity 14
state Variable (depends on authentication configuration)
message Variable (depends on authentication configuration)
sqlazure.is_azure_connection True

For example, if SQL authentication is disabled on the SQL managed instance, the state is 170 and the message indicates that Microsoft Entra-only authentication is enabled.

SQL error logs

In sp_readerrorlog, failed logins from the connectivity test appear as pairs of rows:

ProcessInfo Text
Logon Error: 18456, Severity: 14, State: <variable>
Logon Message depends on authentication configuration

For example, when SQL authentication is disabled, the message states that Microsoft Entra-only authentication is enabled and includes a subnet IP address.

Related content

  • Last updated on