List all replicas of a Docker Swarm service with docker service ps nginx

If you’re exploring Docker Swarm or just keeping a service environment tidy, one of the first things you want to know is this: how many replicas of a given service are actually up and running right now? Take nginx, for example. You might assume a quick glance will tell you, but the truth is a bit more nuanced. The clean, practical way to see all the replicas for a service named nginx is to run: docker service ps nginx.

What does that command actually give you?

Let me explain in plain terms. In Swarm, a service isn’t just one thing—it’s a collection of tasks, and each task is essentially one replica of the service. When you type docker service ps nginx, you’re asking Docker to list every task associated with the nginx service. You’ll get a row for each replica that’s supposed to exist, and you’ll see details like:

• The task ID

• The node where the task is running

• The current state (for example, RUNNING, FAILED, or PENDING)

• The desired state (usually RUNNING if you’ve configured a replicated service)

• The current state’s message (which can tell you if something’s about to be re-scheduled or if there’s an issue)

This view is incredibly practical because it shows you not only that a replica exists, but where it lives and whether it’s actually healthy at this moment. It’s a snapshot you can trust when you’re keeping an eye on reliability across a cluster.

Why this beats other commands for this particular task

You might be tempted to reach for a few other Docker commands to peek around, but each one serves a different purpose. Here’s how they differ, and why docker service ps nginx is the right tool when you want the replicas:

• docker service ls

This is your overview tool. It lists the services themselves—their names, modes, and some high-level stats. It’s great for a quick inventory, but it doesn’t enumerate the individual replicas within a service. If you want to know how many services you have, this is the starting point. If you want to know how many replicas a single service has, it won’t give you the full picture.

• docker container ls

Here you’re looking at containers, plain and simple. It shows what’s running on the host at this moment. If a service has multiple replicas, you might end up chasing containers one by one. But containers don’t map cleanly to service replicas in a multi-node Swarm; they’re the underlying building blocks. The connection between a service and its replicas is handled by the orchestration layer, not by this command alone.

• docker service inspect nginx

This gives you configuration details of the service—like the image, the number of replicas configured, ports, env vars, and the scheduling mode. It’s fantastic for understanding how the service is intended to run, but it doesn’t enumerate the current state of each replica. If you want to know whether those replicas are actually up and where they’re running, you’ll want docker service ps nginx.

How to read the output like a pro

Here’s a quick mental model you can use the next time you run docker service ps nginx.

• Each line corresponds to a replica (a task). If your service runs with three replicas, you should see three lines, unless some are in transition.

• The STATE column tells you what’s happening right now. RUNNING means the replica is healthy and serving requests. STARTING or PENDING is a heads-up that it’s coming up. FAILED or REJECTED signals a problem that deserves attention.

• The NODE column shows where the replica sits. If you’re troubleshooting latency or regional issues, this is your map.

• The DESIRED STATE column is a reminder of how you want the service to behave. If a replica is running, but the desired state is stopped, something’s off in the orchestration layer.

Beyond the basics: little tricks that make life easier

If you’re building a dashboard or just want a cleaner view, there are small knobs you can turn:

• Short IDs: docker service ps nginx -q will print the task IDs only. Handy if you’re cross-referencing with logs or other tooling.

• Full IDs and details: docker service ps nginx --no-trunc gives you the complete task IDs and full state messages. It’s useful when you’re debugging a flaky replica and need every morsel of information.

• Custom formats: docker service ps nginx --format '{{.ID}} {{.Name}} {{.Node}} {{.CurrentState}}' lets you tailor the output to your workflow. If you’re scripting, a touch of format customization goes a long way.

A practical, bite-sized workflow for day-to-day ops

If you’re juggling a swarm, here’s a straightforward rhythm that keeps you in the loop without getting tangled in the weeds:

• Step 1: Get the big picture

Start with docker service ls to see which services are in play and what their high-level status looks like.

• Step 2: Check the replicas

Run docker service ps nginx to list each replica. Look at STATE and NODE to gauge health and distribution.

• Step 3: Verify the configuration

If something looks off, peek at the service’s intended design with docker service inspect nginx. Confirm the expected replica count and the placement constraints (if you’ve set any).

• Step 4: Drill into issues

If a replica isn’t RUNNING, check the current state message, then potential causes like node health (docker node ls), resource pressure (CPU, memory), or network issues.

A few common scenarios you’ll encounter

• A replica stuck in STARTING

This often means the scheduler is trying to bring it up but something’s delaying it—perhaps image pull, a constraint, or a node issue. Patience, then a closer look at the node where it’s attempting to run.

• A replica marked as FAILED

This is your red flag. Look at the error text in the CURRENT STATE column and cross-check with docker service inspect and docker logs for the service tasks if your setup helps you route logs that way.

• A replica running on a less-than-ideal node

If you see skewed distribution, you might want to revisit placement constraints or add more nodes to balance the load. It’s a common operational touchpoint, not a crisis.

Connecting it back to real-world situations

When you’re managing a fleet of microservices, being able to confirm “how many copies of nginx are alive and where” isn’t a luxury—it’s a reliability habit. If a user hits your app and a node goes dark mid-request, the orchestration layer should re-schedule that task to another healthy node. Watching docker service ps nginx helps you verify that automatic recovery in real time, so you can respond quickly, not after the damage is done.

A friendly note on mindset

You don’t need to memorize every flag or option to be capable here. What matters is the intuition: a service in Swarm is a living plan with replicas, allocated across nodes, managed by the orchestrator. The command docker service ps nginx is your lens into that living plan. It’s the doorway to understanding replication, health, and scheduling all at once.

Closing thought: keep the flow going

If you’re curious about how this fits into larger workflows, think of it like this: the swarm gives you a birds-eye map, and docker service ps nginx lets you zoom in on each ship in the fleet. When the waves get choppy, that precise view helps you decide where to steer next. And yes, nginx is just one example—swap in any service name, and the same logic applies. The more you practice peering into those service tasks, the more natural it becomes to spot anomalies, understand why they happen, and keep your microservices singing in harmony.

Bottom line

The exact command to list all replicas for a service named nginx is docker service ps nginx. It’s the fastest, most direct route to the per-replica picture you need. Pair it with docker service ls for context and docker service inspect for intent, and you’ve got a solid, human-friendly toolkit for staying on top of a swarm-based world.