Console commands

php craft microscope/scan/run                       # scan and print the result
php craft microscope/scan/run --verbose             # include how to fix each finding
php craft microscope/scan/run --category=templates  # one area only
php craft microscope/scan/run --fail-on=critical    # non-zero exit for CI
php craft microscope/scan/scheduled                 # run only if the schedule says so
php craft microscope/scan/report --pdf=report.pdf   # export a stored scan as a PDF
php craft microscope/scan/list                      # recent scans
php craft microscope/scan/checks                    # the catalogue
php craft microscope/scan/prune 20                  # keep the last 20

`scan/run`

Runs a scan in the foreground, stores it like any other, and prints a summary. This is the default action, so php craft microscope/scan does the same thing.

Option	Does
`--category`, `-c`	Restrict the scan to one area: `php`, `database`, `server`, `craft`, `schema` or `templates`.
`--verbose`, `-v`	Print every finding’s remediation, not just its headline.
`--fail-on`	Exit non-zero if any finding is at or above this severity: `critical`, `warning` or `notice`.
`--pdf`	Write the report to this path as a PDF.
`--notify`	Send the configured notification email.

Using it as a deploy gate

--fail-on is what makes this useful in a pipeline: a build can refuse to ship a change that turns OPcache off or leaves devMode on.

# Fail the build on anything critical
php craft microscope/scan/run --fail-on=critical

# Stricter: fail on warnings too, and print the fixes into the build log
php craft microscope/scan/run --fail-on=warning --verbose

# Just the templates, as a pre-merge check on a branch
php craft microscope/scan/run --category=templates --fail-on=warning

The template area is the best candidate for a per-branch check: it reads files rather than runtime state, so it gives the same answer in CI as it does in production. Runtime areas are better checked after a deploy, against the real server.

Careful gating the PHP area in CI. A build runner’s PHP configuration is not your web server’s. A CI box with no OPcache will fail a --fail-on=critical gate on the PHP area every single time, no matter how well production is configured. Gate on --category=templates or --category=schema in CI, and scan the runtime areas from the server.

`scan/scheduled`

Checks whether a scan is due and starts one only if it is. Designed to be run hourly from cron; see Scheduled scans.

0 * * * * cd /path/to/site && php craft microscope/scan/scheduled

`scan/report`

Exports a stored scan as a PDF file. With no argument it exports the most recent scan; pass a scan ID for a specific one.

php craft microscope/scan/report                      # latest scan, auto-named, into the current directory
php craft microscope/scan/report 142                  # a specific scan
php craft microscope/scan/report --pdf=audit.pdf      # to a path you choose

Without --pdf, the file is written to the current working directory under a generated name. This command always produces a PDF, so it needs dompdf installed; if you don’t have it, open the print view in the control panel instead.

`scan/list`

The recent scans, with their date, trigger, score and problem counts — useful for finding the ID of the scan you want to export.

`scan/checks`

The full catalogue: every check’s handle, area, name and whether it is currently enabled. The handles printed here are what disabledChecks takes in a config file.

`scan/prune`

Deletes all but the most recent scans. With no argument it uses the retention setting; pass a number to override it.

php craft microscope/scan/prune 20

Pruning also happens automatically after each scan, so this is only needed when you want to reclaim space immediately or have just lowered the retention setting.

The CLI caveat, once more

A scan run from the command line reads the CLI PHP configuration — usually a different memory_limit, a different max_execution_time, and very often no OPcache. Microscope records which SAPI each scan came from and the PHP findings say so, but for the PHP area a scan started from the control panel describes the site more accurately. See Running a scan.

Next: Permissions