AWS Builder Center

Builder Center

My Docker Container Was Running. My Application Wasn't — What I Learned About Debugging Cloud Deployments

A container showing Running doesn't necessarily mean your application is working. Here's the practical troubleshooting approach I learned while working with Docker, networking, and AWS deployments.

bingo

🚨 docker ps Said "Up"... So Why Was My Application Down?

One of the most useful lessons I've learned while working with Docker and AWS is that "running" and "working" are two completely different things.
When I first started working with containers, my mental model was simple:
1
2
3
Container is running
↓
Application should work
But real deployments quickly proved otherwise.
A container can be running while:
  • The application isn't listening on the expected port
  • The port mapping is incorrect
  • Another service can't reach it
  • A database connection is failing
  • A security group is blocking traffic
  • A load balancer health check is failing
  • The application is listening only on 127.0.0.1
  • An environment variable is incorrect
That's when I started approaching troubleshooting differently.

🔍 I Started Debugging Layer by Layer

Instead of randomly changing configurations, I started asking a sequence of questions.

1. Is the container actually running?

1
docker ps
If it's not running, I check:
1
docker logs <container>
The logs usually give the first clue.

2. Is the application actually responding?

A running process doesn't guarantee a healthy application.
For example, an API might expose:
1
GET /health
and return:
1
2
3
{
"status": "ok"
}
This gives infrastructure a meaningful way to determine whether the application is actually responding.

3. Is the port correct?

This is one of the easiest places to make a mistake.
For example:
1
2
ports:
- "8081:80"
means:
1
2
3
Host Port 8081
↓
Container Port 80
So accessing:
1
localhost:8081
reaches port 80 inside the container.
Understanding this mapping becomes even more important when a load balancer or another container is involved.

🌐 Then Comes Networking

Imagine:
1
2
3
4
5
6
7
Internet
↓
Load Balancer
↓
Application
↓
Database
Every arrow represents a possible failure point.
The application might be perfectly healthy, but:
  • The load balancer can't reach the target
  • The target port is wrong
  • A security group blocks traffic
  • The application is listening on the wrong interface
  • The database isn't reachable
  • The health check is hitting the wrong endpoint
This is why "the application works on my machine" doesn't necessarily mean "the application works in AWS."

❤️ Health Checks Changed How I Think About Reliability

A load balancer shouldn't simply ask:
"Is the server alive?"
It should ask something closer to:
"Can the application actually respond?"
That's the purpose of health checks.
For example:
1
2
3
4
5
GET /health
↓
HTTP 200
↓
Target = Healthy
Now the infrastructure has evidence instead of assumptions.

🧠 The Debugging Model I Use Now

When something isn't reachable, I work from the inside out:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Is the process running?
↓
Is the application responding?
↓
Is it listening on the correct port?
↓
Is the container port mapped correctly?
↓
Can the network reach it?
↓
Are security rules allowing traffic?
↓
Is the load balancer forwarding correctly?
↓
Is the health check correct?
This approach is much more useful than changing five configurations at once and hoping something works.

☁️ What AWS Taught Me

AWS has hundreds of services, but many cloud troubleshooting problems eventually come back to a few fundamentals:
Processes.
Ports.
Networks.
Permissions.
Health checks.
Logs.
Dependencies.
Once you understand those, services like EC2, ECS, ALB, ECR and VPC start making much more sense.

🚀 My Biggest Takeaway

The biggest improvement wasn't learning another AWS service.
It was changing the question from:
"Why isn't my application working?"
to:
"At which layer is the communication failing?"
That small change makes troubleshooting much more systematic.
And I think that's one of the most important skills to develop when learning Cloud and DevOps:
Don't just learn how to deploy something. Learn how to find it when it breaks.
# aws-community# aws-community-builders# docker# aws-networking# devops
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article