Why your Docker container keeps restarting

Your app is not really “running” if it starts, crashes, and comes back every few seconds like a light bulb flickering in a bad socket.

Short version: when a docker container keeps restarting, Docker is usually doing exactly what it was told to do: restart the container after the main app process exits. The real problem is inside the container or around it: a missing setting, a bad database connection, a port conflict, a file permission issue, not enough memory, or a restart rule hiding the crash.

Why does a Docker container keep restarting?

A Docker container is like a lunchbox built around one main meal. If that main process ends, the container is considered finished.

That is normal for one-time jobs, but not normal for a web app, database, queue worker, or background service that should stay alive. If Docker sees that the process stopped and the container has a restart policy, it starts it again. Then it stops again. Then it starts again.

That loop is what people mean when they say “my Docker container keeps restarting.” You may also see the exact status string Restarting, Restarting (1), or Exited (1) in Docker tools.

The important thing: the restart is a symptom, not the cause. Docker is the guard repeatedly opening the door. The app inside is the person who keeps walking out.

If Docker itself still feels unclear, start with the plain-English guide to Docker on a server for beginners. It makes the container/app/host relationship easier to picture.

What do Restarting (1) and Exited (1) mean?

Exited means the container’s main process stopped. The number in brackets is the exit code, which is the process’s way of leaving a note on the table.

Exited (0) usually means “I finished successfully.” That can be fine for a short task, but suspicious for a web app that should keep serving visitors.

Exited (1) usually means “something went wrong.” It is a general error, like a check-engine light. It tells you there is a failure, but not which part failed.

Restarting (1) means Docker noticed the process failed and is trying again because a restart policy says it should. That policy can be useful after a real server reboot, but confusing during troubleshooting because it keeps covering the crash with a fresh start.

A restart policy is not a fix. It is an automatic retry. If the app is missing its database password, retrying every ten seconds will not invent the password.

What usually causes a Docker restart loop?

The most common cause is a bad environment variable. An environment variable is a setting passed into the container, such as a database address, secret key, app mode, or API token. If one is missing or mistyped, the app may quit immediately.

The next common cause is a dependency that is not ready. Your web app may start before the database is accepting connections. From your point of view, “everything is up.” From the app’s point of view, it knocked on the database door and nobody answered.

Port conflicts can do it too. If two services both want the same public doorway, one of them loses. The losing app may crash because it cannot bind to the port it needs.

File permissions are another quiet troublemaker. A container might need to write uploads, logs, cache files, or database data to a mounted folder. If that folder belongs to the wrong user, the app hits a locked filing cabinet and exits.

Memory problems can look similar. If the server runs out of RAM, the system may kill the process to protect itself. That can feel random: the container runs for a while, then dies under load. If the whole server feels sluggish too, the guide on why your server is slow will help you separate app crashes from resource pressure.

Finally, the image itself may be wrong for the job: wrong version, wrong architecture, broken release, or an app command meant for setup instead of long-running service. In that case the container is doing what the image told it to do, just not what you expected.

How do you find the real cause without guessing?

Start with the container logs. Logs are the app’s diary. They often say the useful part plainly: “cannot connect to database,” “permission denied,” “address already in use,” “missing secret,” or “out of memory.”

Then check what changed right before the loop began. Did you edit a setting? Update an image? Move files? Change a domain? Add another project to the same server? Restart loops often begin after a small change that looked unrelated.

Look at the timing too. If the container dies instantly, think missing settings, bad command, missing files, or permissions. If it runs for minutes and then dies, think memory, disk, traffic spikes, background jobs, or a dependency that becomes unavailable.

Do not ignore the restart policy. Temporarily seeing the container in a stopped state can be useful because it freezes the scene of the crash. Otherwise Docker keeps cleaning up the evidence by starting over.

Also check whether one project is interfering with another. This happens more often on a shared server with several websites, databases, and workers. A tidy layout matters; otherwise one new service can steal a port, fill storage, or change assumptions for everything else. If that is your situation, the guide on hosting multiple websites on one server is worth reading.

FAQ

Is Docker broken if my container keeps restarting? Usually no. Docker is often following a restart rule. The app inside the container is what you need to inspect.

**Does Restarting (1) always mean the same problem?** No. It only says the main process failed with exit code 1 and Docker is retrying. The logs tell you the real reason.

Can a container restart because the server is too small? Yes. Low memory, full disk, or heavy traffic can kill or destabilize containers, especially databases and busy web apps.

Should every container have an automatic restart policy? Not always. It is useful for stable long-running services, but it can hide a bad setup during testing.

The shortcut

Server Manager helps by keeping the moving parts visible instead of scattered across memory, notes, and old guesses. When a container restarts because of a missing setting, a wrong port, a failing database connection, or a resource squeeze, you have a clearer map of what belongs to that project and what changed around it.

The real benefit is that the setup stays legible months later. You are less likely to wonder which domain points where, which service depends on which database, or whether one project is quietly breaking another.

That does not make app bugs disappear. It does reduce the mess around them, so you can spend your time on the actual failure instead of reconstructing the whole server from scratch.

What does a stable fix look like?

A stable fix is not “make Docker restart harder.” It is removing the reason the app exits.

That may mean correcting a missing environment variable, waiting for the database properly, freeing memory, fixing file ownership, changing a conflicting port, or rolling back a bad image update. Once the cause is gone, the restart policy goes back to being a safety net instead of a loop machine.

Your win is simple: the container starts once, stays up, and behaves predictably. No flicker, no guessing, no mystery Restarting (1) stealing your evening.