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, not just that containers are running.

​
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. 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 
sitectl verify [flags]

​
Output formats

The --format flag controls how the report is rendered:
FormatDescription
sectionHuman-readable sections (default)
tableCompact table
jsonMachine-readable JSON
yamlMachine-readable YAML

​
Common workflows

# Run the active plugin's default verification checks after an update
sitectl verify

# Render a compact CI-friendly report
sitectl verify --format table

# Verify expected Islandora component behavior
sitectl verify --fcrepo off --iiif triplet --bot-mitigation on
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.