What this shows
Paste a workflow file and see what GitHub actually does with it: which events trigger a run, and — more usefully — the real job execution order computed from every needs: reference, not just the order jobs happen to be written in. Jobs with no dependency between them are grouped into the same "wave" and run in parallel; each later wave waits for everything in the wave before it to finish.
Each job card shows its runner (or, for a reusable workflow call, the workflow file it invokes), what it needs:, and its steps in order — a quick way to see a workflow's actual shape without mentally tracing needs: chains by hand, especially once a pipeline grows past three or four jobs.
What it doesn't do
This assumes the workflow is already valid — it doesn't check for structural errors or broken references (use GitHub Actions Validator for that) or security issues like script-injection risk (use GitHub Actions Linter) or how secrets flow through the workflow (use GitHub Actions Secrets Checker). A needs: entry pointing at a job that doesn't exist is silently dropped from the graph here rather than flagged.
FAQ
Why do jobs run in "waves" instead of one at a time?
GitHub starts every job whose dependencies have already finished as soon as a runner is available, so independent jobs genuinely run concurrently rather than queuing one after another. The waves shown here are the actual concurrency GitHub extracts from your needs: graph, not just a linear reading order.
What does a circular needs error mean?
If job A needs B and B needs A (directly or through a longer chain), there's no valid starting point — GitHub detects this and refuses to run the workflow at all, rather than deadlocking. This tool runs the same dependency check so you can see the cycle before pushing.