Access and Use the Argo Workflows UI (2026)

The Argo Workflows UI is not just a dashboard; it’s a live, interactive representation of your workflow execution graph, allowing you to debug and monitor jobs with unprecedented visibility.

Let’s see it in action. Imagine you’ve submitted a simple workflow:

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hello-world-
spec:
  entrypoint: whalesay
  templates:
  - name: whalesay
    container:
      image: docker/whalesay
      command: ["cowsay"]
      args: ["hello world"]

When you submit this using argo submit --watch your_workflow.yaml, the UI will immediately show a single node representing the whalesay template. As the container starts, the node color changes from gray (pending) to blue (running). Once it completes, it turns green. If it fails, it turns red.

You can click on the whalesay node. A side panel slides out, showing you the logs. For this simple workflow, you’d see:

____________
< hello world >
------------
    \   ^__^
     \  (oo)\_______
        (__)\       )\/\
            ||----w |
            ||     ||

This is the core interaction: the UI visualizes the workflow’s Directed Acyclic Graph (DAG), and each node is a clickable entity providing detailed status and logs.

The Mental Model: From YAML to Visual

Argo Workflows transforms your YAML definition into a series of steps that are executed as Kubernetes pods. The UI is the window into this process.

Workflow CRD: You define a Workflow Custom Resource (CR) in Kubernetes. This CR is the blueprint.
Workflow Controller: The Argo Workflows controller watches for these Workflow CRs. When it sees one, it starts orchestrating.
DAG Generation: The controller translates your entrypoint and templates into a sequence of steps, often represented as a DAG.
Pod Creation: For each step (or template execution), the controller creates a Kubernetes Pod.
UI Connection: The Argo Workflows UI (which is a separate deployment, typically running as a Service in your cluster) queries the Kubernetes API server for the status of these Workflow CRs and their associated Pods. It then renders this information visually.

You control the workflow’s execution through the Workflow CR:

entrypoint: The starting template.
templates: The reusable building blocks of your workflow. These can be container templates (running a Docker image), script templates (running inline scripts), resource templates (managing Kubernetes resources), or dag templates (for complex branching logic).
arguments: How you pass data between steps.
outputs: How steps declare results that can be passed to subsequent steps.

Debugging with the UI

When a workflow fails (the node turns red), the UI becomes invaluable. Clicking the node reveals the error message. Often, it’s a failed status from Kubernetes. The logs are paramount. You’ll see the exact output from the container that failed.

Consider a workflow that tries to kubectl apply a non-existent resource:

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: kubectl-fail-
spec:
  entrypoint: apply-fail
  templates:
  - name: apply-fail
    resource:
      action: apply
      manifest: |
        apiVersion: v1
        kind: NonExistentResource
        metadata:
          name: test-resource

Submitting this and checking the UI would show a red node. Clicking it would reveal logs from the argo-resource-apply container, likely containing a Kubernetes API error like:

error: unable to recognize "STDIN": no matches for kind "NonExistentResource" in version "v1"

This tells you the resource template failed because Kubernetes rejected the NonExistentResource kind.

The UI also allows you to re-trigger failed steps, resume completed workflows, and even cancel running ones, all directly from the interface.

The "Why" Behind the Visual

The Argo Workflows UI doesn’t just fetch data; it actively listens for changes. When a workflow is running, the UI client in your browser is subscribed to Kubernetes events related to that workflow. This means you see status updates in near real-time without needing to refresh the page. The UI is built using React and communicates with the Argo Workflows API server, which in turn queries the Kubernetes API. This event-driven architecture is what makes the UI feel so responsive.

You might notice that when you have a very large workflow with hundreds of nodes, the UI can sometimes feel sluggish. This isn’t a problem with the Kubernetes API, but rather with the browser’s ability to render and manage that many DOM elements efficiently. Argo is constantly evolving to optimize this rendering.

The next step in understanding Argo Workflows involves exploring how to pass complex data between steps using artifact passing.