Skip to main content
check asks the platform to validate the workflow definitions on the revision and prints what it says back. It uploads nothing and compiles nothing — it checks what is deployed right now, which may or may not be what your working tree holds. Reach for it after a push, which never checks, or after a deploy that reported a failure and stopped at the first one.

​
Synopsis

​
What it does

  1. Resolves the blob and revision. This is a read, so phase commit is allowed alongside draft and managed.
  2. Lists the revision’s definitions and matches the manifest against them.
  3. Calls check_definition for each manifest entry that is workflow-category and present on the revision. Playground entries are skipped, and so is any entry the revision does not have — both without an output line of their own.
  4. If every check passed, prints one line per definition with each event indented beneath it, as type: component_id: message — component_id appears only on the events that carry one:
That info event is what a clean definition looks like: the platform emits it when it found nothing else to say. Under --json the payload carries status, checked — each entry with its status and the checker’s raw events — and drift, alongside the envelope’s schema_version. If any check failed, none of that is printed. The failures are collected into a single CHECK_FAILED error on stderr, naming each failing definition and its events, and the command exits 1:
deploy reports the first failing check; check reports all of them. That is the reason to re-run it after a failed deploy.

​
HTTP 200 does not mean the check passed

check_definition answers 200 OK with {"status": "failure", "events": [...]} in the body. The CLI keys off the body’s status and never off the HTTP status — a tool that gates on the HTTP status alone reports a broken workflow as valid. This is worth remembering if you drive the API directly. It is not an error path: a failing check is a successful call whose result is “no”.

​
What the checker actually validates

Structure, and only structure: A passing check therefore means the definition is structurally runnable, not that it works. Compile-time guarantees about your Python come from build; runtime behaviour comes from running it. success can still carry events. Only an error event decides failure — warning and info events travel in the same list and leave the status alone. Read the events on a passing check rather than stopping at the status line. A freshly created definition legitimately fails. create_definition writes an empty stub with no components at all, so it has no flow.start and the checker says so. That is the expected answer for a definition nothing has been uploaded into yet, not a defect in the CLI or the platform.

​
Errors

A manifest entry that is not on the revision is not an error here — check has nothing to check and moves on. diff is what reports that gap. Every code above, with its remediation, is in Error codes.

​
See also