Worker errors
A PHP error on the site, a worker that will not load, a lock that is held.
"Worker error"
The platform reached the site and got a PHP error back. The Health page shows what the site said. If the error is in another plugin or the theme, fix it on the site as you would any fatal error. If it is in the worker itself, the worker's own rollback puts the previous version back without loading the plugin — the platform does that itself when it detects a failed worker update — and on a site the platform cannot reach, uploading the current zip over the install is the manual equivalent. Recovery.
The worker will not load
If the plugin's files are incomplete, the worker stays out of the way rather than breaking the site on every request. The site works without it; the platform reports it as unreachable with the cause. Reinstall the current release.
"Another operation is running"
The site is busy with a backup, a restore or a worker update. The platform waits and asks again; nothing is needed from you. A lock left behind by a crashed process expires after fifteen minutes on the site, and the platform releases its own hold on a site when the operation ends. A site that stays busy for longer than half an hour with nothing running is a defect; report it with the site and the time.
A page cache answers for the site
If a site's data does not change when it should — a plugin updated on the site, the list still showing the old version after a sync — a page cache in front of the site may be answering. The worker marks every answer to the platform as not cacheable, so this is rare; where it happens, exclude the wp-json/wpocto/v1 path in the cache's settings — the same path the site's Health page names when the platform finds a cache answering for the worker.
Where to look on the site
Octo Tools → Error log and Activity log, and the worker's debug log under wp-content/uploads/wpocto-log/.