Nothing Was Down. Except the Application

Nothing Was Down. Except the Application.

02:07 AM.

"The app is down."

That's all the ticket says.

You check the container.

dns-client is Up.

CPU looks normal. Memory looks normal. No obvious application crash.

So you try the endpoint:

curl http://localhost:8000/fetch

Nothing.

You wait.

Still nothing.

The logs aren't helping either. No useful stack trace. No obvious connection error. Just an application that appears to be waiting for something that never arrives.

You exec into the container.

The application is running. The network interface is there.

Then you try resolving its dependency:

nslookup api.internal

And suddenly, the investigation changes.

The application isn't necessarily broken.

It may not even be reaching the API.

You start following the request backward—from the application, to the container's resolver configuration, to the local DNS cache, and finally to the upstream DNS behavior.

One tiny configuration detail can change how a container searches for a name. Another can determine which resolver actually receives the query. A stale cache can make the problem even more confusing: it works once, then mysteriously fails again.

Now the question isn't "Why is /fetch broken?"

It's:

"What is the container actually asking DNS—and who is answering?"

This is the kind of incident that makes production troubleshooting difficult. The application can be perfectly healthy while the dependency it needs is effectively invisible.

At InfraThrone, you don't just read about incidents like this—you get dropped into them. Follow the evidence, inspect the infrastructure, challenge your assumptions, and find the failure hiding behind the symptom.

Because at 2 AM, the answer rarely lives where the error appears.