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
Section titled “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.
Live status
Section titled “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.
The failing step
Section titled “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
Section titled “Per-node logs”Open a node in a run to read its logs. Where the logs come from depends on how your connector is set up:
- By default the connector points dagweave at the log location in your own storage, so the bytes never pass through dagweave.
- If you run Loki, the connector can ship logs there and dagweave reads them back inline.
Log retention depends on your plan. Pro keeps logs for failed steps for 24 hours, so you can debug a failure; Business keeps more, for 14 days and beyond.
Metrics
Section titled “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
Section titled “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
Section titled “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.