GitHub Actions Validator
Workflow YAML Linter & Explorer

It checks YAML syntax and duplicate keys, required on and jobs keys, event names and filters, job and step structure, needs references and dependency cycles, permissions scopes, cron schedules, workflow_dispatch and workflow_call inputs, expression syntax and context availability, matrix size, and common security risks such as script injection and unpinned third-party actions. Each finding links to its line.

Valid YAML is not automatically a valid workflow. The usual causes are a job without runs-on, a step with both uses and run, a needs entry pointing at a misspelled job, a misspelled event or key, an expression in a place that does not allow that context, or a duplicate key. The findings list explains each one in plain English.

Schedules use UTC, run only from the default branch, and are queued rather than guaranteed - runs at the start of an hour are often delayed or dropped during peak load. In public repositories, schedules are also disabled after 60 days without repository activity. Pick an off-peak minute such as 17 instead of 0.

In YAML an unquoted 3.10 is a number, and the number 3.10 is the same as 3.1. Quote version numbers in a matrix, such as "3.10". The validator flags every unquoted version with a trailing zero, and the Matrix Builder always quotes them.

GitHub multiplies every list in the matrix, removes combinations that match an exclude entry, then applies include: an include entry extends the combinations it does not contradict, or becomes a new job if it contradicts all of them. The Jobs and Steps view shows the resulting job count, and a matrix may produce at most 256 jobs.

Not directly. Secrets cannot be referenced in if conditionals. Set the secret as an environment variable at the job level, for example HAS_TOKEN: the secret value, then test env.HAS_TOKEN in the step's if. The validator reports a direct secrets reference in any if.

Expressions inside run are pasted into the shell script before it runs. If one contains text an attacker controls - an issue title, a pull request body, a branch name - they can inject shell commands. Pass the value through env instead and reference it as a quoted variable. The validator warns about the attacker-controlled github.event fields.

For third-party actions, yes. A tag like v1 can be moved by its owner, or by an attacker who compromises the repository, and your workflow silently runs the new code. A full 40-character commit SHA cannot change. The validator notes unpinned third-party actions; GitHub's own actions (the actions and github organizations) are not flagged.

No. Formatting re-writes the workflow from its parsed structure with consistent indentation, and YAML parsers do not keep comments. Use it on a copy, or copy your comments back afterwards. Validation never changes your text.

No. Parsing and validation run entirely in your browser. The validator never contacts GitHub or any other server, so private repository workflows, environment names, and internal runner labels stay on your device.