Executions

Once a cluster is connected through the connector, every run shows up in dagweave. The executions view is where you watch runs happen, read their logs, see how a workflow is doing over time, and start a run again. It needs the connector to submit and observe runs, so it needs a plan that includes them.

The run history

Every run lands in a history list, newest first, for a single workflow or across all of them. Each run carries a phase:

Pending while it is queued.
Running while it is in flight.
Succeeded, Failed, or Error once it finishes.

You can filter the history by phase, so it is quick to pull up just the failures. A run also records how it started (a manual button, a cron schedule, a webhook, a GitHub event, an SNS message, or the API), so you always know why a given run happened. This list is the runs dagweave dispatched. The connector also reports Workflows nobody started from dagweave, from CronWorkflow children to argo submit at a terminal, and those are stored and listed separately: see runs you did not start.

Live status

A running workflow updates in place. dagweave streams status as the run progresses and tints each node on the canvas by its phase, so you watch the run move across the graph you built. While it runs it shows the elapsed time and a rough estimate of how much time is left, taken from the median duration of the same workflow’s recent successful runs. If the stream drops behind a proxy, dagweave falls back to polling so the view never stalls. A step stuck at Pending names the lock it is queued behind, or says no node can take its pod: see why a run is not moving.

Where the time went

Open a run and its steps are bars on one clock, each split at the moment the container started, so queueing for a pod reads apart from doing the work. Sort by duration and the step that owned the run goes to the top. See the run timeline.

The failing step

When a run fails, dagweave surfaces the step that failed and its error message, both in the history and on the canvas. On the canvas it pulls focus to the failed node, and clicking the failure jumps the view to that node on the graph, so you can tie a failed step back to a node on your screen. It points you at the failing step; it does not try to diagnose the cause for you.

Per-node logs

Open a node in a run to read its logs. Whether they appear here at all depends on which sink your connector ships to:

S3 or an S3-compatible bucket. The connector reports a location under your own bucket and dagweave points you at it, so the bytes never pass through dagweave.
A dagweave-hosted Loki. dagweave reads the lines back and renders them inline. This is the one sink where log bytes leave your cluster for dagweave.
Your own Loki, an HTTP endpoint, or the chart’s default console sink. These receive the logs, but dagweave has no way to read them back, so nothing shows up in this panel. Read them wherever you sent them.

How long dagweave keeps logs depends on your plan, and the app shows your window. Every step is kept for that window, whether it failed or not. Those windows apply to the logs dagweave reads back for you. Logs sitting in your own bucket last as long as your own storage policy keeps them.

Metrics

Each workflow has a metrics view over a recent window (30 days by default): how many runs finished and how many succeeded, a success rate, runtime averages with p50 and p95, a runs-over-time chart, and a breakdown of which trigger source started the runs. The same view is available across all your workflows at once. It is enough to see whether a workflow is healthy and getting slower or flakier.

Re-run

Any run can be started again from its entry in the history. dagweave re-dispatches the same workflow to the same cluster and namespace with the same runtime parameters, so you can retry a failure or repeat a run without setting it up again.

Failure notifications

dagweave can tell you when a run fails so you do not have to watch the history. A team turns on failure notifications and picks where they go:

Email to the team owner or an address you set.
Slack, posted to an incoming-webhook URL you configure for the team.

The message names the workflow, the failing step, the error, and links back to the run. Notifications fire once, on the first time a run reaches a failed state. The same toggle and channels also alert you the first time a connector goes offline, so a silently dead connector does not go unnoticed. There are no success notifications today.