Learn how to view the running services in a Docker stack using the docker stack services command.

Outline (skeleton)

• Hook: managing a Docker Swarm stack is like keeping tabs on a busy ship; you need the right command at the right time.

• Part 1: The four commands in question, and which one truly shows stack-wide service info

• Quick, simple explanations of:

• docker service ls (or docker service list)

• docker services inspect

• docker stack ls

• docker stack services

• Why docker stack services is the one that ties services to a stack

• Part 2: What a “stack” means in Docker Swarm

• Stacks group services deployed together, often via a compose file

• How this helps in real-world apps with multiple moving parts

• Part 3: How to use docker stack services in practice

• A concrete example: docker stack services mystack

• What you’ll typically see: replicas, mode, current state, image

• Tips for formatting and quick filtering

• Part 4: Common gotchas and how to work around them

• Swarm must be initialized, correct context, stack name right

• Part 5: Related commands you’ll likely encounter

• A few quick references to stay fluent in the ecosystem

• Part 6: Takeaways

• The practical value of knowing this one command well

• The article ends with a human, relatable note about handling multi-service deployments

Article

When you’re juggling a Docker Swarm with several services, you want a single, reliable way to see what’s actually running for a given stack. It’s a bit like glancing at the cockpit of a small airline: you want clear indicators, not a wall of numbers. The command that does this neatly for a stack is docker stack services. It lists every service that belongs to that stack, showing status, replicas, mode, and the image in use. If you remember just one thing from this, let it be that docker stack services ties the service view directly to the stack you’re working with.

But let’s slow down for a moment and place this in context. You’ll often see other commands in the same family:

• docker service ls (or docker service list): this gives you the services in the swarm broadly, not necessarily tied to any particular stack. It’s useful for a big-picture glance, but it can feel detached if you’re debugging a specific application comprised of multiple services under a single stack.

• docker service inspect: this digs into a single service, pulling out configuration details, current constraints, and exact state. It’s like focusing a lens on one widget in a larger machine.

• docker stack ls: this shows you which stacks exist, but it won’t tell you what those stacks are running inside in the way docker stack services does.

Here’s the thing: when you want to understand how a whole stack is performing—what services are active, how many replicas are up, and whether there are any drift issues—docker stack services is the right tool. It’s purpose-built for that stack-scoped insight. It’s especially handy in environments where a single project has multiple microservices deployed together, all orchestrated by Swarm.

What exactly is a “stack,” and why does it matter?

A stack in Docker Swarm is a collection of services deployed as a unit. Think of a stack as a little orchestra: you’ve got a web front-end service, a back-end API service, a database service, maybe a cache service, all interacting through shared networks. When you deploy a stack with docker stack deploy, you typically reference a compose file (that familiar docker-compose.yml, reinterpreted for Swarm). The moment the stack goes live, the services start running, replicas are assigned, and the orchestration layer handles scheduling across the nodes.

Knowing the health and status of these services—within that exact stack—makes it easier to diagnose issues quickly. Instead of hunting through the swarm’s global service list and trying to map items back to your app, docker stack services mystack presents a clean, focused picture. It’s a productivity amplifier, especially when you’re collaborating with others on multi-service architectures.

A practical peek: what does docker stack services actually show?

Run a command like this:

• docker stack services mystack

What you’ll typically see (the fields can vary a bit by version, but the gist is consistent):

• ID: a short, unique identifier for the service

• NAME: usually something like mystack_web or mystack_api, clearly tied to the stack and the service

• MODE: replicated or global tells you how the service scales

• REPLICAS: how many tasks are desired and how many are running

• IMAGE: the container image currently in use for the service

• PORTS: any published ports and how they’re exposed

• STATE or CURRENT STATE: a snapshot of what’s actually happening now (for example, whether replicas are up and healthy)

If you want a quick, readable view, you can use the --format option to tailor the output. For example:

• docker stack services mystack --format "table {{.Name}}\t{{.Replicas}}\t{{.Image}}\t{{.Mode}}"

This kind of formatting helps you scan quickly, especially when you’re juggling multiple stacks and want to keep a live dashboard in your terminal.

A helpful mental model: compare it to a team roster

Picture a team roster for a project. docker stack services is like pulling up the roster for a specific project name. You see who’s on the team (service names), how many players should be on each line (replicas), and who’s actively on the field (CURRENT STATE). If a player goes missing or a line isn’t fully staffed, you catch it fast and plan the next move. That clarity is exactly what you want when you’re maintaining reliable services in production.

Common gotchas (so you don’t stumble)

• Swarm context matters: The command assumes you’re operating in a Docker Swarm context. If Swarm isn’t initialized on the current daemon, you’ll get errors. Make sure you’ve run docker swarm init or you’re connected to the right Swarm manager.

• Stack name accuracy: The command needs the correct stack name. A small typo and you’ll be staring at a blank or unrelated set of services. Double-check the name you pass to docker stack services.

• Permissions and scope: If you’re working across multiple clusters or environments, ensure your Docker context is pointing to the right environment. A misplaced context can make it look like nothing is running when, in fact, it’s a different cluster.

• Output interpretation: Don’t expect every service to report the same state if there are ongoing updates or rollouts. The REPLICAS column may show desired counts while current states lag during rollout or scaling.

If you’re new to this, a quick workflow might look like:

• docker stack deploy -c docker-compose.yml mystack

• Wait a moment for scheduling

• docker stack services mystack to confirm the current picture

• If something looks off, docker service ls or docker service inspect can help pinpoint a problematic service within the stack

Tying it together with related commands

As you work with stacks, you’ll often combine a few commands seamlessly:

• docker stack ps mystack: see the tasks (the actual running instances) for each service

• docker stack deploy -c stackfile.yml mystack: deploy or update the stack with a compose-like file

• docker stack rm mystack: remove a stack when you’re done with it

All of these feel natural once you’re comfortable with docker stack services as the central snapshot of a stack’s health.

A quick digression that helps with intuition

If you’ve ever managed a small project at work, you know the value of a clean status board. In software, that board isn’t a corkboard with sticky notes; it’s the terminal or dashboard that reflects current realities. docker stack services is a compact, readable board for your Swarm-based stacks. It’s not flashy, but it’s dependable. And in the long run, dependability matters more than spectacle—especially when you’re maintaining complex apps with several moving parts.

Putting the pieces into a broader toolkit

Beyond the stack-focused command, you’ll encounter a few other patterns as you work with Docker in more depth:

• Troubleshooting: if replicas aren’t reaching the desired state, inspect the service with docker service inspect and check the events and constraints around placement. Sometimes a node failure or a network issue is the culprit.

• Observability: consider pairing stack service views with logs and metrics. Docker’s logging drivers, or an external tool, can give you a clearer picture of performance and errors across the stack.

• Deployment workflows: you’ll often deploy stacks from a versioned compose file, keeping changes under version control. That discipline pays off when you need to roll back or reproduce environments.

A friendly reminder about the broader picture

Docker Swarm is one orchestration option among others, like Kubernetes. Each choice has its own approach to scaling, service discovery, and fault tolerance. The key takeaway here is that, in Swarm, the stack-centric view—provided by docker stack services—lets you see the health and configuration of a whole group of services as a single entity. That perspective is incredibly valuable when you’re coordinating multiple services that must work in harmony.

Takeaway: why this command matters

In day-to-day operations, you’ll reach for docker stack services to answer: Which services belong to this stack? How many replicas should be running, and how many actually are? Is the current state keeping pace with the desired state? This command gives you a concise, stack-focused snapshot, enabling quicker decisions and smoother maintenance. It’s a small tool, but it has a big impact on staying in control of multi-service deployments.

If you’re exploring Docker at a professional pace or working toward the Docker Certified Associate topics, keep this command close at hand. It’s not the only tool you’ll use, but it’s a reliable compass when you’re navigating a swarm-lit landscape of services and stacks. And who knows—this simple visibility might spark insights that help you optimize performance, reliability, and collaboration across your team.

In short: when you need a clear, stack-relative view of running services, docker stack services is your go-to. It ties the whole picture together, so you can focus on what matters—keeping your applications smooth, predictable, and ready to scale as needs evolve.