Skip to main content
Think of the checks in three layers: validate is for configuration and project layout, healthcheck is a basic status check for the running application, and verify is the healthcheck layer plus additional plugin-owned functionality tests. Use verify in CI after site updates to make sure important site behavior still works, beyond confirming that containers are running. Verification also consumes the same component plan as validate and converge. A site cannot report successful behavior while its desired component state is missing, ambiguous, or unapplied.

​
Reference

Run plugin verification checks for the active site. Verification checks are deeper behavioral checks implemented by the active context’s plugin. They are intended for CI, preview, development, and staging deployments after healthcheck has already confirmed the site is online. Before reporting success, verify consumes the same component reconciliation plan as converge and validate. Behavioral checks cannot hide missing desired state, unknown component ownership, or unapplied component changes. All flags not consumed by sitectl itself are forwarded to the plugin’s verify handler, allowing plugin-specific flags such as --fcrepo or --bot-mitigation. Examples: sitectl verify sitectl verify --format table sitectl verify --bot-mitigation on

​
Output formats

The --format flag controls how the report is rendered:

​
Common workflows

Only failed results make the command exit non-zero. Warnings are rendered in the report but do not fail the command.

​
Plugin verification

Core sitectl invokes the active context plugin’s registered verify runner and renders the returned results with the same report formats used by validate and healthcheck. The plugin decides which functionality checks matter for that application. Flags that core does not consume are forwarded to the plugin’s verify handler. For the Islandora plugin this includes expected-state flags such as --fcrepo, --blazegraph, --iiif, --iiif-topology, --bot-mitigation, and --isle-file-system-uri. Some plugin checks can intentionally mutate a disposable site. For example, Islandora’s --demo-objects check creates demo content and verifies repository content grows, so it is meant for CI, preview, development, or staging contexts rather than production.