Your cron is dead. We get it running again.

Most single cron or indexer bugs are a Quick Fix at $99 (~4h @ $25/hr) — a missing crontab line, one stuck indexer, or a single jammed job. A batch of related issues or one gnarly root cause (jammed cron_schedule + broken MView triggers + dead consumers) is a Bug-Fix Sprint at $499 (~20h @ $25/hr) with regression tests. Production-down emergencies use a custom retainer with a 24/7 SLA. You get the fixed price before any work starts.

First we check the crontab for the line * * * * * php bin/magento cron:run (and the matching setup:cron:run). If it is missing we run bin/magento cron:install and confirm the user, PHP binary and path are correct. Then we watch the cron_schedule table to confirm jobs move from pending to success. A dead cron is the most common reason emails, the sitemap and indexers all "stop working" at once.

Rows stuck in running usually mean a previous cron:run crashed mid-job and never released the slot, so new runs overlap and skip. Rows piling up as missed mean cron fell behind its schedule_lifetime window. We clear the stale rows safely, fix whatever job was hanging, and tune the cron group config (schedule_generate_every, schedule_lifetime, use_separate_process) so the queue stops clogging.

Yes. We run bin/magento indexer:status to see which indexer is frozen — commonly Product Price, Catalog Search or Stock. A status stuck on processing normally means a reindex was killed and never reset, or a lock is held. We reset the indexer state, run indexer:reset if needed, then a clean indexer:reindex, and confirm every row reports Ready.

That error comes from a stale lock in the index_indexer_state table after a reindex was interrupted (deploy, killed process, OOM). We confirm no reindex is actually running, then clear the lock for that indexer and rerun the reindex cleanly. We never just delete locks blindly — we first verify nothing is mid-write so we do not corrupt the index.

A indexer:reindex that hangs is usually memory pressure, a slow database, or the EAV/flat tables fighting. We profile the slow indexer, raise the relevant batch sizes, run heavy indexers individually instead of all at once, and switch noisy indexers to "Update by Schedule" so they reindex incrementally via MView instead of full rebuilds. On very large catalogs we schedule the full reindex for off-peak.

On "Update by Schedule" mode Magento relies on MySQL triggers writing into changelog tables, tracked in mview_state. If the triggers were dropped (common after a raw DB import or a partial migration) the changelog stops growing and edits never get picked up. We rebuild the triggers — toggling the indexer mode regenerates them — verify the changelog tables fill again, and confirm a test edit reflects on the frontend.

Almost always, yes. Order/transactional emails are queued and sent by the message-queue consumers, and the XML sitemap is generated by a scheduled cron job — both die silently when cron is dead or its consumers are not running. We restore cron:run, confirm the consumers_runner config and the sitemap / email cron jobs, then trigger a regeneration so the backlog clears.

We reproduce on staging first wherever one exists, capture the exact CLI output, and prove the fix there before going near production. If there is no staging we work on live with extra care — read-only diagnosis first, a backup of the affected tables (cron_schedule, index_indexer_state, mview_state), and changes during a quiet window. Cron and indexer fixes are low-risk when sequenced properly.

Yes. Cron and indexer work is mostly configuration and state cleanup, not code that ships to the frontend, so the blast radius is small. We back up the relevant tables before touching them, clear stale rows rather than truncating whole tables, and run a clean reindex that the storefront keeps serving the old index during. If anything looks off, we roll back the state and reassess — your shoppers never see a half-reindexed catalog.

Yes, this is common. After setup:upgrade the indexers are marked invalid and need a reindex, new cron groups may need re-installing, and a partial deploy can leave a reindex lock behind. We reset and reindex everything, reinstall the crontab if it was wiped, and rebuild MView triggers that the upgrade dropped. If the upgrade itself is unstable we also look at our Magento upgrade bug fixing path.

Yes. Every Quick Fix comes with a 7-day warranty on the same bug; Sprints include 14 days of post-fix coverage. If the cron job dies again or the indexer re-locks from the same cause, we fix it at no extra charge. We also add a lightweight watchdog so a future silent failure pages us instead of hiding until your emails or sitemap quietly stop.