Every API endpoint returned 500 errors. The logs revealed two MongoDB issues I wasn't expecting.

Today started with a nightmare scenario for any backend developer.

Every API endpoint in my application suddenly started returning 500 Internal Server Errors.

At first, I assumed it was something I had recently deployed. I reviewed the latest commits, checked the deployment pipeline, verified environment variables, and inspected application logs.

Nothing obvious stood out.

Then I enter the VPS. Check the docker logs.

I noticed repeated MongoDB errors appearing throughout the logs:

DNSException: querySrv ESERVFAIL
_mongodb._tcp.cluster0.mongodb.net

Naturally, I thought the outage was caused by a MongoDB connectivity issue. The symptoms matched perfectly: database failures, followed by API failures.

But after digging deeper, another error kept showing up:

MongoServerError: Index build failed

E11000 duplicate key error
collection: roles
index: id_1
dup key: { id: null }

This turned out to be the real clue.

MongoDB was attempting to build a unique index on the id field, but multiple documents already existed with id: null. The index build failed, which caused repository initialization issues and eventually surfaced as 500 errors across the application.

What made this incident interesting was how misleading the symptoms were.

The API looked broken.

The database connection looked broken.

But the actual root cause was a data integrity issue hiding inside the collection.

A few reminders I took away from today's debugging session:

✅ When every endpoint fails, look for shared dependencies.

✅ The first error you see isn't always the root cause.

✅ Database indexes deserve the same attention as application code.

✅ A single bad document can trigger failures across an entire system.

Debugging distributed systems is often less about fixing code and more about following evidence until the story finally makes sense.

Today, that story ended with a duplicate MongoDB index failure hiding behind a wall of 500 errors.

While debugging this from the frontend side, I used a tool I built for inspecting network traffic Network Spy, which helped me trace the root cause faster: Check it here