Before you start
Check hosting access, WordPress scheduling, PHP limits, image libraries and writable storage. Agree a maintenance window for configuration changes.
A recognisable example
DYMR has little traffic overnight. Image jobs should still progress, so its agency checks a reliable host schedule instead of waiting for a customer to visit.
Step by step
- Inspect queue state, last progress and errors for the affected feature. Confirm that jobs belong to the intended shop and source files.
- Check whether WP-Cron is disabled or visitor traffic is too low to trigger it reliably. Configure a supported system schedule or runner through the host when needed.
- For local images, verify Imagick or GD, source and output limits, disk capacity and protected staging storage. Respect locks, retry limits and execution budgets.
- Run a small supported job and verify its result and manifest. Monitor a second scheduled run; one manual success does not prove that recurring execution works.
What you should see
The supported queue can progress without loading heavy processing into a customer request. Originals and the last valid output remain important recovery sources.
If it does not work
Jobs keep failing? Preserve the error and source reference, check resource limits and repair the cause. Do not delete locks, increase retries indefinitely or move customer files to a central server as an unapproved fallback.
Menu names and available actions depend on your app language, permissions and connected shop. Screens show the real Daymerce interface with fictional DYMR data; original screen labels are preserved.