Swarm deployment rollback not reflected in Dokploy UI (deployment appears successful even when tasks fail healthcheck)

[qwent71]

To Reproduce

Description

When deploying an application using Docker Swarm with health checks and rollback configuration enabled, Dokploy does not clearly indicate that a deployment failed and rolled back.

The new tasks fail the health check and exit, while the previous healthy task remains running, which is expected behavior from Docker Swarm. However, the Dokploy UI and deployment logs do not clearly mark the deployment as failed or rolled back.

This makes it difficult to detect failed deployments from the UI.

---

Expected Behavior

When a new deployment fails due to a health check failure and Docker Swarm performs a rollback, Dokploy should:

• clearly mark the deployment as failed
• indicate that a rollback occurred
• show the final deployment status (failed / rolled back)
• optionally display the reason (healthcheck failure)

Example expected UI state:

Deployment status: Failed (Rolled back)
Reason: Healthcheck failed

---

Actual Behavior

Deployment logs show the image being pulled and pushed to the internal registry, but there is no clear indication that the deployment failed.

Example logs:

Pulling registry.example.com/project/backend:latest
Image is up to date
Image pushed to registry

However, inspecting the running containers shows:

• new containers created and quickly exiting
• old container remaining running (healthy)

Example:

exited backend-service-task-1
exited backend-service-task-2
running (healthy) backend-service-old

This indicates that the rollout failed and the previous version remained active.

---

Steps to Reproduce

1. Configure a service with:

   • Docker Swarm deployment
   • Health Check enabled
   • Update Config Failure Action = rollback

2. Deploy a version where /health returns 500

3. Observe:

Docker Swarm behavior:

• new task starts
• healthcheck fails
• task exits
• previous healthy task remains running

Dokploy behavior:

• deployment logs appear normal
• UI does not clearly indicate failure or rollback

---

Environment

Dokploy version: (fill in)

Deployment type:

• Docker provider
• Docker Swarm mode enabled

Healthcheck example:

CMD-SHELL
curl -f http://localhost:3000/health || exit 1

---

Additional Context

Rollback works correctly at the Docker Swarm level.
The issue appears to be related to how Dokploy reports the deployment status in the UI.

Currently the only way to detect a failed rollout is by inspecting Docker directly:

docker service ps <service>
docker ps

It would be helpful if Dokploy exposed the final deployment status more clearly.

---

Current vs. Expected behavior

Current behavior

After deploying a new version of the application using Docker Swarm with health checks and rollback configuration enabled, Dokploy does not clearly indicate that the deployment failed.

When the new version fails the health check:

• new service tasks are created
• those tasks exit shortly after starting
• the previous healthy task remains running

This indicates that Docker Swarm correctly prevented the rollout and kept the previous version active.

However, the Dokploy UI and deployment logs do not clearly show that the deployment failed or that a rollback occurred. The deployment process appears successful from the UI perspective.

The only visible indication of the failure is by inspecting the service containers or tasks manually.

Example observed state:

exited backend-service-task-1
exited backend-service-task-2
running (healthy) backend-service-old

---

Expected behavior

When a deployment fails due to a health check failure and Docker Swarm prevents the rollout (or performs a rollback), Dokploy should clearly reflect this in the UI and deployment logs.

The deployment should be marked as failed or rolled back, and the UI should indicate that the new version did not become active.

For example:

Deployment status: Failed
Reason: Healthcheck failed
Previous version kept running

This would make it much easier to detect failed deployments without manually inspecting Docker service tasks.

---

Provide environment information

Operating System:
    OS: Ubuntu 24.04.4 LTS
    Arch: x86_64
  Dokploy version: 0.28.6
  VPS Provider: Other
  What applications/services are you trying to deploy?
    Bun (Elysia) backend as Docker container (oven/bun:1.3.10-slim)

Which area(s) are affected? (Select all that apply)

Docker

Are you deploying the applications where Dokploy is installed or on a remote server?

Remote server

Additional context

No response

Will you send a PR to fix it?

No

[dosubot]

Hi @qwent71! I'm Dosu and I’m helping the dokploy team.

This is a known limitation in how Dokploy handles Docker Swarm deployments. The issue is that Dokploy marks deployments as successful immediately after the service.update() API call completes, without waiting to verify that:

• Tasks actually start and reach running state
• Healthchecks pass
• The service converges to the desired state
• Swarm doesn't trigger an automatic rollback

The relevant code in application.ts shows this pattern:

await mechanizeDockerContainer(application);
await updateDeploymentStatus(deployment.deploymentId, "done");
await updateApplicationStatus(applicationId, "done");

This has been reported in several related issues:

• #2911 - Old containers keep running when new ones fail to start
• #2682 - Traefik ignores unhealthy containers but UI shows success
• #1557 - Feature request to show healthcheck failures in UI

Workaround: Until this is addressed, you'll need to verify deployments manually using:

docker service ps --no-trunc <service-name>

This will show the actual task states, including failed healthchecks and rollbacks that Dokploy doesn't currently surface.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[DCUnit711]

Hit this exact failure mode today on v0.28.8 (also confirmed unfixed in v0.29.1 by reading source). Posting our reproducer + the workaround we shipped, in case it helps anyone landing on this issue.

Reproducer

1. Deploy app version A successfully (any image that boots cleanly).
2. Push image B that throws at startup — e.g. process.env.X validated as required, X not in env. Image build/push succeeds.
3. Workflow calls application.update → application.saveEnvironment → application.deploy.
4. Swarm pulls B, starts task, task fails (task: non-zero exit (1)), RollbackConfig reverts to A.
5. docker service ls shows 1/1 replicas. docker service ps shows the new task lineage as Failed → Shutdown and the old A task still Running.
6. Dokploy UI shows applicationStatus: done. The deployment is marked successful. The OLD code keeps serving traffic.

The drift is invisible until something specific to B is exercised. We discovered this only when a secret rotation appeared to take effect in Doppler + Dokploy + the workflow logs but the live container kept validating the old secret.

Root cause (as I read the source)

mechanizeDockerContainer in packages/server/src/utils/builders/index.ts calls:

await service.update({
  version: ...,
  ...settings,
  TaskTemplate: {
    ...settings.TaskTemplate,
    ForceUpdate: inspect.Spec.TaskTemplate.ForceUpdate + 1,
  },
});

That's correct as far as it goes — ForceUpdate++ does request a new task even when the image hash is unchanged. But the promise resolves as soon as the swarm manager accepts the spec, not when the new task is healthy. deployApplication then marks the deployment done. By the time RollbackConfig kicks in, Dokploy has already stopped paying attention.

Workaround we shipped (not a Dokploy patch)

Each app exposes GET /api/build-info returning {sha, builtAt}, sourced from a GIT_SHA build-arg. Our deploy workflow polls this endpoint after Dokploy reports success and asserts the served SHA matches the just-pushed github.sha. If swarm rolled back, the served SHA stays at the previous build → workflow fails with a clear message instead of green-on-red.

Worked first run: caught a stage app that had been silently stuck on a 2-day-old image (every newer deploy had failed startup, swarm had rolled back, Dokploy reported each as success).

A potential upstream fix sketch

After service.update(...), poll service.tasks({ filters: { service: [appName] } }) until either:

• the most-recent task has Status.State === "running" AND Spec.ContainerSpec.Image === <new image> → success
• a more-recent task than what's running has Status.State === "failed" or "rejected" → fail the deployment with the task error message
• timeout (UpdateConfig.Monitor + 2× UpdateConfig.Delay would be a safe ceiling)

Happy to throw together a PR if there's interest. We picked the per-app /api/build-info route because it also catches "Dokploy says image X but Docker pulled :latest cached as Y" type drift, but the upstream fix is the more obviously-correct one.

[mattias-wiberg]

This is a significant UX gap. Right now a deployment can "succeed" while the actual service is silently rolling back and a developer has no idea unless they happen to check /dashboard/swarm. For a platform whose entire value proposition is making deployments observable and manageable, this is a blind spot. Would love a PR @DCUnit711

[Siumauricio]

Confirmed. mechanizeDockerContainer resolves once the Swarm manager accepts the new service spec, and the deployment is marked done right after — task startup, healthchecks and RollbackConfig all happen after Dokploy has stopped watching, so a rolled-back deploy shows green while the old image keeps serving.

@DCUnit711 your convergence-polling sketch is the right shape (poll service tasks until the newest task for the new image reaches running, fail on failed/rejected with the task error, ceiling derived from UpdateConfig.Monitor/Delay) — a PR along those lines is very welcome. Two things to keep in mind: it needs to be opt-in-safe for services without healthchecks (where "running" is quick), and the wait should happen inside the deployment job so the status/logs land in the existing deployment record.

[Siumauricio]

Reproduced and confirmed on v0.29.13 with a real Swarm rollback.

Test: application deployed as a Swarm service with healthCheckSwarm and updateConfigSwarm.FailureAction = rollback.

1. Deployed with a passing healthcheck → task Running, Dokploy status done.
2. Changed the healthcheck to a failing command and hit Redeploy.

Docker's view:

$ docker service inspect <svc> --format 'UpdateStatus: {{.UpdateStatus.State}} - {{.UpdateStatus.Message}}'
UpdateStatus: rollback_completed - rollback completed

Dokploy's view:

applicationStatus: done
Deployments tab: "1. Done — Rebuild deployment"  (green)

So the rollout failed its healthcheck, Swarm rolled back to the previous task, and Dokploy reports the deployment as successful with no indication that a rollback happened. The deployment log ends normally because the docker service update call itself returns success — the rollout outcome in .UpdateStatus.State is never inspected afterwards.

Note the useful signal is already available right after the update: UpdateStatus.State returns rollback_completed / rollback_paused / paused on failure vs completed on success.

Confirmed; keeping open.

[arditramaj1]

Hello guys! I think that this feature is very important to understand how the deployment healthcheck failed. Is this planned for any future release?

[bestmaa]

I opened #5218 with a focused fix for this.

It now waits for the current Swarm service update to finish before marking the deployment complete. Paused and rolled-back updates become deployment failures, and the deployment error includes the latest failed task reason and exit code when available.

I verified both paths on a real local Swarm: a healthy update reached completed, while an unhealthy task triggered an automatic rollback that was reported as a failure. Reviews and suggestions are welcome.

[arditramaj1]

@bestmaa Thanks a lot for the attention on this issue. I think it is a very good addition to dokploy's blue green deployment setup possibility

[tiklup11]

thanks @bestmaa
faced the same issue today, spent hours figuring out the RCA in my app.