What it looks like

The dashboard is Markdown, so here is one: an example from made-up rows, rendered by Sluiceway's own code, with every section at once.

In a real dashboard issue you tick its boxes; here they are disabled. The same body, as a dashboard issue holds it, is assets/example-dashboard.md.

Sluiceway: deploying, 4 stacks are pending, some changes delete or replace resources

Read the dashboard from the top

The header. Penny with four crates upstream, one per pending stack, water running downstream because two stacks deploy, and both signs: a pending row deletes resources and another replaces one. The header shows every picture.
The counts line. How many stacks are pending, drifted, deploying, preview failed and in sync, each behind its count dot, how many pending stacks delete or replace resources, and, only when there is one, how many stacks are busy. Under it, the scan line says which commit the last scan checked out, when, in which run, and when the last full scan was. While a scan runs, a scan-running line under it says since when and links the run, which this example does not show. Neither does it show the lines about runs that failed: a run that failed before Sluiceway ran, or found a problem in sluiceway.yaml, says so under the scan line, and the next scan that works counts the runs that failed since the one before.
Deploying. While a stack deploys, its section comes before every other. apps/api:prod deploys, and its row starts with a spinner. apps/worker:prod is a queued stack: it waits for the stack it depends on. Both rows say ticked by. A stack set to deploy on merge would say deploying on merge · merged by instead, which this example does not show. When a deploy is cancelled or rejected, its row turns into a preview failure within seconds, says no preview since its deploy ended, and carries its failure line until the next scan previews the stack.
Updates waiting to merge. This section is there when merge and deploy is on. platform/ingress-nginx:prod is an update waiting to merge: one tick merges its pull request, and its stack is previewed again and deployed. apps/web:prod is an update waiting on its checks, a line with no box that ends in waits on its checks. It gets its box once its checks are green.
The destroy alert. A caution block above the pending rows names every pending stack that deletes or replaces resources, here apps/legacy-worker:prod and infra/network:prod, and in a paragraph of its own every drifted stack with a resource gone outside the code. The deletes themselves stay under that stack’s row.
A pending row. apps/billing:prod has one create and one update waiting. Its row links the preview, names the pull requests that brought the change, links the compare view, and folds the changes under their count. Tick its box to deploy that stack exactly as its row shows it. With cost estimates on, an OpenTofu or Terraform row has a cost line under its first line, and a row whose change fails a policy has no box and names the policy instead. This example shows neither.
A row with deletes. apps/legacy-worker:prod deletes three resources. A destroy is listed first, outside the fold, and always carries a warning.
A row with changes outside the stack. apps/web:staging names the pull requests its stack claims and folds one change that no stack claims, such as a lockfile bump, since it may reach any stack.
A row with a replace. infra/network:prod replaces a subnet, and says which property forces it. The change came from a direct push, so the row names a commit instead of a pull request.
The bulk box. Deploy all 4 pending stacks, under the pending rows. A tick on it deploys nothing. It asks for a confirm box instead. There is no bulk box in a section with one row, with deploys off, or on a read-only dashboard.
Drifted rows. Real infrastructure changed outside the code. monitoring/grafana:prod has a property changed, and platform/external-dns:prod has a record gone. Deploying a stack puts it back as its code says. A stack whose drift check failed keeps its row as it was and says drift not checked.
The confirm box. Someone ticked Repair all 2 drifted stacks, and the next run put a confirm box where the bulk box was. It names the stacks and who asked. A tick on the confirm box deploys them, as a tick on each row. Each stack is judged by its own tick rule and gets its own fresh preview. If a row changes before anyone ticks the confirm box, the confirm box goes and the bulk box comes back.
Preview failed and Busy. A stack whose preview failed twice in one scan, after its second try, sits under Preview failed. Its row has no box, says why, and links the run whose job log holds the tool’s own words. A busy stack, one whose lock another update held on both tries, sits under Busy. Its row starts with busy:, names the reason, another update holds the stack's lock, and says that the next scan previews it. Nothing is wrong with it, and the header does not turn failing. This example shows neither section.
In sync. The stacks with nothing to deploy, folded under their count, and under them the stacks left out by ignore, each with its reason.
Recently deployed, the trail. Every deploy that ended, newest first, one line each: its result dot, the stack id, its ticker (or merged by for a deploy on merge), the date and time in UTC, and a link to its run. A deploy that went out can have a shipped line under it. A full scan adds the outside deploys it finds in the tool’s own history, such as data/postgres:prod here. A failed deploy stays listed when a later deploy of its stack clears the failure line on the row.
The rescan box. Tick it to start a full scan of every stack. It deploys nothing.

What it looks like

Deploying

Updates waiting to merge

Pending

Drifted

In sync

Recently deployed

Read the dashboard from the top