Cosmos DB Mongo API unreachable in North Europe & UK South – repeated outage, ECONNREFUSED

Question

Cosmos DB Mongo API unreachable in North Europe & UK South – repeated outage, ECONNREFUSED

Suneth Thotagamuwa 40

Problem Description: We are experiencing a critical outage affecting multiple Azure Cosmos DB Mongo API accounts across North Europe and UK South. All affected accounts suddenly became unreachable at the same time.

This is the second time we have experienced a major Cosmos DB Mongo API outage.

Current Symptoms:

Clients receive ECONNREFUSED when connecting to the MongoDB endpoint.

DNS resolution succeeds (nslookup resolves the hostname).

TCP connectivity tests from PowerShell fail with:
- WARNING: Name resolution failed
- TcpTestSucceeded : False
Issue is reproducible from multiple networks and machines.
Backend metrics (CPU, RU/s, storage) are normal for all accounts.
No firewall, VNet, or IP allowlist changes were made.
Multiple independent Cosmos DB Mongo accounts are impacted simultaneously across two regions.

Impact: This is a production‑impacting outage. Applications cannot connect to Cosmos DB at all. No read or write operations are possible. Given the previous incident resulted in significant data loss, this recurrence is extremely concerning.

Accounts/Regions Affected:

North Europe
UK South

Assessment: Based on the symptoms, this appears to be a Cosmos DB Mongo API gateway or regional routing outage affecting multiple regions simultaneously. The recurrence of this issue raises concerns about the reliability of the Mongo API gateway layer.

SAI JAGADEESH KUDIPUDI 3,550 Reputation points Microsoft External Staff Moderator

2026-06-19T17:50:34.9233333+00:00

Hi @Suneth Thotagamuwa ,
Thank you for reaching out and sharing the details regarding the Cosmos DB Mongo API connectivity issue.

We understand the impact this is causing, and we truly appreciate your patience. Please allow us some time to review this behavior internally and verify the situation from our end. We are actively checking with the relevant teams and will get back to you with an update shortly.
Manoj Kumar Boyini 17,950 Reputation points Microsoft External Staff Moderator

2026-06-22T10:13:50.8466667+00:00

Hi @Suneth Thotagamuwa

Kindly run the following command from one of the affected client machines and share the output:

PowerShell
Test-NetConnection <server-hostname | ip-address> 10260

Connection with Mongosh:
mongosh mongodb+srv://<user>:<password>@<accountName>.mongocluster.cosmos.azure.com/?tls=true&authMechanism=SCRAM-SHA-256&retrywrites=false&maxIdleTimeMS=120000

check if DNS resolves to expected IPs
$ nslookup -type=SRV _mongodb.tcp.<cluster-name>.<domain>
Suneth Thotagamuwa 40 Reputation points

2026-06-22T10:24:18.0266667+00:00

Hi Manoj,

Please see the output:
Sina Salam 30,486 Reputation points Volunteer Moderator

2026-06-22T13:49:36.35+00:00
Hello Suneth Thotagamuwa,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Cosmos DB Mongo API unreachable in North Europe & UK South – repeated outage, ECONNREFUSED.

I saw this as a critical issue and yet unresolve for the past three days, this shows diagnostic steps are not the solution, just for evidence collection. The immediate recovery path is either:

Microsoft Internal restores the affected MongoDB gateway/listener/routing path; or

Azure Support performs a point-in-time restore of the affected MongoDB vCore cluster to a new healthy cluster, then the application is repointed after successful DNS, TCP, TLS, and mongosh validation.

Please ask the Severity A support engineer to escalate to the Cosmos DB for MongoDB vCore product group and provide backend correlation plus RCA/PIR.

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.
Manoj Kumar Boyini 17,950 Reputation points Microsoft External Staff Moderator

2026-06-23T14:55:48.8933333+00:00

Hi @Suneth Thotagamuwa

Please use the shared link in Private Message to create the SR.

Answer accepted by question author

0 additional answers

Your answer

SAI JAGADEESH KUDIPUDI 3,550 Reputation points Microsoft External Staff Moderator

2026-06-19T17:50:34.9233333+00:00

Hi @Suneth Thotagamuwa ,
Thank you for reaching out and sharing the details regarding the Cosmos DB Mongo API connectivity issue.

We understand the impact this is causing, and we truly appreciate your patience. Please allow us some time to review this behavior internally and verify the situation from our end. We are actively checking with the relevant teams and will get back to you with an update shortly.
Manoj Kumar Boyini 17,950 Reputation points Microsoft External Staff Moderator

2026-06-22T10:13:50.8466667+00:00

Hi @Suneth Thotagamuwa

Kindly run the following command from one of the affected client machines and share the output:

PowerShell
Test-NetConnection <server-hostname | ip-address> 10260

Connection with Mongosh:
mongosh mongodb+srv://<user>:<password>@<accountName>.mongocluster.cosmos.azure.com/?tls=true&authMechanism=SCRAM-SHA-256&retrywrites=false&maxIdleTimeMS=120000

check if DNS resolves to expected IPs
$ nslookup -type=SRV _mongodb.tcp.<cluster-name>.<domain>
Suneth Thotagamuwa 40 Reputation points

2026-06-22T10:24:18.0266667+00:00

Hi Manoj,

Please see the output:
Sina Salam 30,486 Reputation points Volunteer Moderator

2026-06-22T13:49:36.35+00:00

Hello Suneth Thotagamuwa,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Cosmos DB Mongo API unreachable in North Europe & UK South – repeated outage, ECONNREFUSED.

I saw this as a critical issue and yet unresolve for the past three days, this shows diagnostic steps are not the solution, just for evidence collection. The immediate recovery path is either:

Microsoft Internal restores the affected MongoDB gateway/listener/routing path; or

Azure Support performs a point-in-time restore of the affected MongoDB vCore cluster to a new healthy cluster, then the application is repointed after successful DNS, TCP, TLS, and mongosh validation.

Please ask the Severity A support engineer to escalate to the Cosmos DB for MongoDB vCore product group and provide backend correlation plus RCA/PIR.

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.
Manoj Kumar Boyini 17,950 Reputation points Microsoft External Staff Moderator

2026-06-23T14:55:48.8933333+00:00

Hi @Suneth Thotagamuwa

Please use the shared link in Private Message to create the SR.

Answer 1

Hi @Suneth Thotagamuwa

The Azure Cosmos DB for MongoDB vCore cluster was reported as unreachable from both a newly created Azure Function App and local client tools such as MongoDB Compass and Mongo Shell.

Findings

The Cosmos DB cluster was healthy and no server-side issues were identified.

Connectivity issues were traced to client-side configuration and network access settings.

Root Cause

The Azure Function App was configured with an incorrect connection string that pointed to a different endpoint. Updating the application to use the connection string provided in the Azure portal restored connectivity. Local client connectivity was affected by IP-based firewall rules and changes in the client public IP address due to VPN usage.

Observations

Existing Function Apps continued to work because established connections were already in use. New connection attempts failed due to endpoint configuration issues and firewall allowlist mismatches.

Recommendations

Always use the connection string generated in the Azure portal without modification.
Ensure the correct client public IP address is included in the firewall allowlist.
Verify outbound connectivity requirements, including access to port 10260.
Consider using a Private Endpoint for more secure and predictable connectivity.

The Function App connectivity issue has been resolved. Investigation of local client connectivity behavior is continuing based on telemetry and network validation.