Workflows
Argo Workflows runs a great deal of Tantilium Cloud Runner's work. The CI/CD pipelines that build your applications run on it, every data and ML pipeline you define runs on it, and many teams run Argo of their own on the clusters they connect. The Workflows area (/workflows) brings all of that into one place. Whatever cluster a workflow ran on, whatever region or cloud that cluster lives in, and whatever started it, you find the run here, watch it progress live, and act on it without ever opening a terminal or the Argo UI of an individual cluster.
One list, every cluster
The run list is a single, cross-cluster table. Each row is one workflow run, tagged with the cluster it ran on along with that cluster's region and provider, the namespace, the template it was started from, its phase, its progress and how long it took. You can narrow the list by phase, by where the run came from (a data or ML pipeline, a Tantilium Cloud Runner (TCR) CI build, or a workflow someone else submitted), by template, by pipeline, by free text and by time window. Platform administrators, and tenants who have been given access to other clusters, can also filter by cluster, region and provider. Every filter is part of the page address, so a link such as /workflows?phase=Failed&since=24h always opens the same view, and that is exactly the link the dashboards use when they report failed runs.
The list never asks you to refresh. TCR watches the Argo Workflow resources on every cluster it knows about and keeps a copy of each run in its own database, and every change to a run is pushed to your browser as it happens. A run that starts somewhere in your fleet appears at the top of the list within moments, and its phase and progress move as it executes. Because TCR keeps that copy, a run's history outlives the run itself: when Argo garbage-collects a finished workflow from its cluster, the run stays in the list, marked as no longer on the cluster, with its graph, its timings and its archived logs intact.
Inside a run
Opening a run shows its execution graph. Every step is a node, coloured by its phase; running steps pulse, and the edges show which steps waited for which. Steps that were retried, or that fanned out over a list of items, are collapsed into the step they belong to with a badge counting their attempts, so a graph stays readable even when a step ran two hundred times. The graph updates live while the run executes.
Selecting a node opens its detail beside the graph: when it started and finished, its exit code, the message Argo recorded for it, the parameters it received and the outputs it produced. Its logs are there too. While the step's pod still exists you can follow its log as it is written; after the pod is gone, TCR reads the log that Argo archived to object storage, so a failure from last week can be investigated as easily as one from a minute ago. A step's output artifacts can be downloaded directly from the panel. They stream through TCR after it has checked that you are allowed to see the run, which means the storage behind them is never exposed to the browser. When you want a second opinion on a failure, the AI Analysis button hands the step's context to the AI assistant.
Acting on runs
From the run page you can retry a failed run, which reruns only the steps that failed and keeps everything that already succeeded, stop a run so that it finishes the steps in progress and then exits cleanly, or terminate it immediately. Templates can also be submitted as new runs. Retries go through Argo's own server on the cluster where the run lives, reached through that cluster's Kubernetes API, so no Argo endpoint is ever published to make this work. When Argo can no longer retry a run in place, TCR resubmits it from the same template with the same parameters instead. Every action is recorded against the run, with who did it, when, and what happened, and that audit trail is shown on the run page.
Runs that belong to TCR's own CI/CD builds are shown here for completeness, but they are managed from Pipelines, which remains their source of truth; the Workflows view links to them rather than acting on them.
Who sees what
Every tenant sees its own runs: the runs of its data and ML pipelines, and its CI builds. Platform administrators see every run on every cluster. Between those two, a platform administrator can grant a tenant access to a specific namespace on a specific cluster from Workflows → Clusters & Access, which is how a team that runs its own Argo installation on a connected cluster sees those workflows alongside the ones TCR runs for it. The same page lists every cluster TCR watches, whether Argo was found on it, where its Argo server is, and when the cluster was last in sync.
Seeing a run and acting on it are separate rights. Reading runs, graphs, logs and artifacts needs nothing beyond belonging to the tenant. Retrying, stopping, terminating and submitting need the workflows:execute permission, which a platform administrator grants to roles in Settings → Permissions; tenant administrators hold it by default. The interface hides the controls you can't use, and the backend enforces the same rule on every request.
On the dashboards
Failed workflow runs are part of the platform's health signal. The main dashboard shows the number of runs that failed in the last 24 hours next to the other cluster health cards, the tenant home page shows the same count for your own runs, and the Workflows entry in the sidebar carries a red dot whenever that count is above zero. Each of them opens the run list already filtered to those failures.
Next steps
- Data Pipelines: define your own extract, validate, transform and load pipelines on Argo Workflows.
- ML Pipelines: train, evaluate, register and deploy models on Argo Workflows.
- workflow-manager: the service behind this area.