Troubleshooting

Zoo says an asset is unused and it is on the homepage

Check the probe list on the census first. If URLs in stored markup did not run — scanContent is off — Zoo never looked inside your content, and an image dragged into a rich-text field creates no relation row at all. Turn it on and take another census.

If it did run, open the finding and look at the evidence. The likely causes, in order:

• The image is hard-coded in a template and template scanning is off, or the templates directory is not readable by PHP. The probe line says which.
• The URL in the markup does not match the asset's URL — a CDN rewrite, an image transform service, a srcset built in JavaScript. Zoo matches on the URL path and on the bare filename; a URL that contains neither is a URL it cannot connect to the asset.
• The reference is built at runtime — asset.url|replace(...), a filename assembled from a field value. Nothing can see that statically.

All three are keep-list cases. Put it on the keep list with the reason, and it never comes back.

A probe says it could not run

Line	What to do
"Content scanning is turned off in settings."	Turn scanContent on.
"Template scanning is turned off in settings."	Turn scanTemplates on.
"Foreign-key scanning is turned off in settings."	Turn scanForeignKeys on.
"The templates directory could not be read."	Check the path and the permissions on templates/. Under Docker this is usually a mount that is not there in the console container.

A census with a probe that did not run is still a census — but every finding in it is a weaker claim, and the screen says so rather than hiding it.

"Other tables keyed into elements" searched 0 places

Zoo reads information_schema for foreign keys into elements.id. Zero means either the database user cannot read information_schema — unusual, but it happens on managed MySQL with a locked-down grant — or the tables have no foreign keys at all, which happens on databases restored with --skip-add-drop-table or imported through a tool that dropped constraints.

The second case is worth fixing for its own sake: without those keys, deleting a user or an element leaves rows behind in every plugin's tables.

The census is slow

It reads every row of elements_sites.content once and walks templates/ and config/ once. On a site with a few hundred thousand content rows that is a minute or two.

• Queue it — that is the default; Run it now is the one that does it in the request.
• Turn off the audits you are not acting on. The schema audits are cheap; unused-assets and unrelated-entries are the ones that do the work.
• Raise minimumAgeDays. It reduces the candidate set before any probe runs.

"That census is more than 60 minutes old"

Take another one. Findings are claims about a moment, and Zoo will not act on a claim old enough for somebody to have used one of the things in it. staleAfterMinutes moves the line if an hour is wrong for your site.

"It has been edited since the census ran"

The element's fingerprint changed between the census and the delete — usually an asset re-uploaded over the top, or an entry saved. That is a different file or a different entry from the one the census was about. Take another census.

Something reappeared after being deleted

It was moved to the trash, not deleted, and something restored it — or the census that reported it predates the restore. Zoo → History has the ledger: what was deleted, how, and when.

A category with no entries is not being reported

It has children. A category that is somebody's parent is never reported, because deleting it would promote its children to the top level rather than remove them. The same is true of structure entries in the unreferenced-entries audit — those are reported, with a warning, because the promotion is the surprising part rather than a reason to hide the row.

Deleting a field did not free any space

It would not immediately. Craft 5 keeps field content in elements_sites.content as JSON, and removing the field removes the key from new saves rather than rewriting every existing row. The space comes back as content is re-saved, or after a project-wide re-save:

php craft resave/entries --update-search-index=0

Nothing happens when I press "Take a census"

It is queued. Check Utilities → Queue Manager. If your queue is not running — no queue/listen daemon and runQueueAutomatically off — use Run it now instead, or run php craft zoo/census/run from a shell.