Find your starting point
A store can load and still be failing.
A 200 response from your homepage tells you that one request succeeded. It does not tell you whether orders can be paid, catalog changes reach shoppers, or yesterday’s background work has finished. A useful health check follows those outcomes.
| What you notice | Investigate first | Recovery evidence |
|---|---|---|
| Old prices or stock visibility | Indexers, cron, cache | A known product change reaches the store |
| Late order emails | Cron, email configuration, provider logs | A new test email reaches the inbox |
| Missing search products | Search, indexing, visibility | An expected product appears in its store view |
| Intermittent checkout failure | Browser requests, payment and logs | Order and gateway state reconcile |
| Background operations stop | Cron runner and consumers | Expected work completes and backlog recovers |
Your first pass
- Confirm the active release, PHP binary and Magento version.
- Inspect indexer status, cache status and recent cron execution evidence.
- Check recent errors and storage headroom.
- Test an expected product search and review a recent order’s payment/email outcome.
- Record anything unresolved in the checklist. Investigate active checkout failures first.
Use the full investigation below when a result is ambiguous. There is no universal “healthy” score: one broken payment path can outweigh nine successful checks.
Scope & prerequisites
These examples assume a conventional Linux-hosted Magento 2.4.x installation with shell access. Cloud, containers, multi-node deployments and managed services need platform-specific scheduling and service checks.
- Run Magento CLI commands from the active application root as the filesystem owner, using the deployment’s PHP binary. Here,
phpis a placeholder for that binary. - The commands below inspect state. They do not intentionally reindex, flush caches, start consumers or change configuration. Magento bootstrap and logging can still write operational files.
- Inspect sensitive output locally. Never publish
app/etc/env.php, credentials, tokens, customer details or raw payment responses.
| Coverage | Magento Open Source / Adobe Commerce 2.4.x; features vary by edition and release |
|---|---|
| Documentation review | Adobe CLI guidance reviewed October 22, 2026 |
| Runtime validation | This article is documentation-reviewed; this exact checklist has not been executed across every 2.4.x release |
| Not established by this guide | Security certification, guaranteed deliverability, complete payment correctness or full disaster recovery readiness |
Establish the environment
A command run against the wrong release or PHP binary can produce misleading evidence.
pwd
php -v
php --ini
php bin/magento --version
php bin/magento deploy:mode:show- Expected result
- The active application directory, intended CLI PHP version and Magento version match your deployment records. Production mode is expected for a conventional production deployment.
- Warning signs
- CLI PHP differs from the web/FPM runtime, the directory points at an old release, or production runs in developer mode without a documented reason.
- What the evidence proves
- CLI output describes this shell environment. It does not establish the PHP version serving browser requests. Verify the configured FPM pool or hosting runtime separately; do not expose a public phpinfo page.
- Next investigation
- Record edition, exact patch version, hosting model, deployment path, timezone and configured PHP binary before investigating other components.
- Verify recovery
- Repeat with the deployment’s PHP binary and filesystem owner. Compare the web runtime through your hosting configuration.
Prove cron is executing work
A working storefront can conceal stopped background work, including scheduled indexing and asynchronous email.
crontab -l
tail -n 80 var/log/cron.log- Expected result
- For a conventional Linux deployment, the application owner has the intended scheduler entry, and recent execution evidence matches the expected schedule. Managed hosting may configure scheduling elsewhere.
- Warning signs
- An entry exists but execution timestamps stop advancing, jobs repeatedly fail, or pending jobs become missed.
- What the evidence proves
- A crontab entry proves configuration, not successful execution. A missing cron.log alone does not prove cron is broken: logging, rotation and hosting differ. Inspect recent cron_schedule records using read-only database access.
- Next investigation
- Check the scheduler service, correct owner and PHP path, then inspect job_code, status, scheduled_at, executed_at, finished_at and sanitized error messages for affected jobs. Respect any database table prefix.
- Verify recovery
- Observe new completed jobs over several expected cycles and confirm the affected business task recovers. Historical success rows alone are insufficient.
Need a deeper investigation? Read Magento 2 Cron Not Running: Diagnose the Failure Before You Restart.
Check indexer status and progress
Outdated indexes can leave shoppers seeing incorrect prices, stock visibility or missing catalog results.
php bin/magento indexer:status
php bin/magento indexer:show-mode- Expected result
- Statuses and configured modes fit the deployment. For scheduled indexes, any backlog progresses after relevant catalog changes.
- Warning signs
- The same indexer stays working or invalid across repeated observations, a backlog grows, or a known product change never reaches the storefront.
- What the evidence proves
- One working snapshot can represent legitimate processing. Ready does not prove every store view has correct business data. Compare timestamps and repeated observations with a known product update.
- Next investigation
- Correlate cron execution, imports, database locks and indexer errors. Do not reset an indexer while its worker may still be running. Reindexing or changing modes requires a planned remediation, not a routine health-check command.
- Verify recovery
- Confirm processing advances, then verify the intended price, category or stock change on the storefront. Customer Grid schedule support differs before and after 2.4.8; consult the version-specific documentation.
Verify message processing
An accumulation of unprocessed work can delay asynchronous operations even when page requests succeed.
php bin/magento queue:consumers:list- Expected result
- Required consumers are registered, and the configured process manager or cron runner processes the queues used by this store.
- Warning signs
- Queue age or depth grows, messages repeatedly fail, or a required consumer continually exits.
- What the evidence proves
- The command lists available consumers; it does not show that they are running or keeping up. An empty queue may be normal on an idle store. The backend may be a database or a supported message broker.
- Next investigation
- Inspect the configured runner and broker metrics through approved operational access. Check consumer logs and expected workload before starting additional workers.
- Verify recovery
- Observe an expected task complete and confirm queue depth and oldest-message age recover. Avoid creating duplicate unmanaged consumers.
Check cache and storefront freshness
Disabled or ineffective caches can increase server load; stale content can hide intended catalog changes.
php bin/magento cache:status- Expected result
- Required cache types are enabled, and the configured full-page cache/CDN behavior matches the deployment.
- Warning signs
- Caches are unexpectedly disabled, anonymous requests consistently miss cache, or updated content remains stale beyond the expected invalidation window.
- What the evidence proves
- Enabled cache types do not prove cache hits or healthy Redis/Valkey, Varnish or CDN behavior. An authenticated session and an anonymous product page can have different caching rules.
- Next investigation
- Compare anonymous response headers, application configuration and upstream cache logs. Trace the affected URL and cache tags before invalidating anything.
- Verify recovery
- Check the same public page after a controlled content change. Confirm freshness and origin load. Do not use cache:flush as a diagnostic shortcut: shared cache storage can contain other applications’ data.
Test search as a shopper
Search service availability alone does not prove shoppers can find purchasable products.
php bin/magento config:show catalog/search/engine- Expected result
- The engine matches the deployment, and a known enabled, visible, in-stock product appears for an appropriate storefront query.
- Warning signs
- Search errors, missing expected products, inconsistent store-view results or repeated search indexing failures.
- What the evidence proves
- Engine configuration does not test connectivity or query relevance. A green service endpoint does not establish Magento’s authentication, index mapping or product visibility.
- Next investigation
- Use Admin’s connection test where available and investigate indexer logs and search service metrics. Keep credentials and private endpoints out of shared diagnostic reports.
- Verify recovery
- Test a known SKU/name, a category result and a no-results query in the affected store view. Compare with expected catalog visibility.
Correlate recurring application errors
A recurring exception can break one customer path while the homepage continues returning 200.
tail -n 100 var/log/system.log
tail -n 100 var/log/exception.log- Expected result
- Recent logs have no unexplained recurring errors correlated with the affected operation. Missing files may reflect logging configuration or no events.
- Warning signs
- A new error repeats after a deployment, timestamps coincide with failures, or errors refer to payment, database, permissions or missing classes.
- What the evidence proves
- Log size is not severity, and an old exception does not prove a current incident. Raw output can include personal data or secrets; redact it before sharing.
- Next investigation
- Group by exception and stack location, record first/last occurrence and correlate a browser request with application and web-server logs. Preserve evidence before rotating or clearing logs.
- Verify recovery
- Reproduce the affected action after remediation and observe a suitable monitoring window. Confirm both the user outcome and absence of the correlated failure.
Inspect infrastructure headroom
Exhausted storage, inodes or memory can interrupt sessions, logging, imports and database writes.
df -h .
df -i .
free -h- Expected result
- Application storage has free capacity and inodes, with sufficient memory headroom for the actual workload.
- Warning signs
- Rapidly declining free space, exhausted inodes, swapping under load, out-of-memory kills or recurring PHP worker saturation.
- What the evidence proves
- These Linux commands show a snapshot. free may describe the host rather than a container limit; also inspect container limits, other mounts and historical service metrics.
- Next investigation
- Review PHP-FPM saturation, database connections/locks, slow queries and search memory through the hosting tools. Use capacity trends and workload context rather than a universal pass threshold.
- Verify recovery
- Observe peak-period metrics and confirm writes, sessions and background processing remain reliable. Avoid deleting files or restarting services before identifying ownership and impact.
Verify the complete customer transaction
Checkout and payment failures directly prevent revenue, regardless of other healthy checks.
Browser workflow: product → cart → shipping → payment → order confirmation → order email- Expected result
- A controlled test produces the correct order, payment state, totals and email without duplicates. Test the store views, shipping and payment paths you actually sell through.
- Warning signs
- Failed browser requests, duplicate capture attempts, incorrect tax/shipping, missing orders after payment or undelivered email.
- What the evidence proves
- A confirmation page alone does not prove payment capture, and payment authorization is not capture. An application email-sent flag does not prove delivery to an inbox.
- Next investigation
- Use staging and gateway sandbox first. A production test can create real charges, stock changes and notifications; plan and authorize it separately. Correlate order, invoice and gateway transaction identifiers internally.
- Verify recovery
- Reconcile the order with the gateway and intended invoice state, then verify mailbox delivery and shipping/tax accuracy. Remove personal and transaction data from public evidence.
Establish recovery and security readiness
A backup that cannot be restored provides little protection during a failed release or incident.
Review: latest backup result, retention, restore rehearsal, patch inventory and monitoring ownership- Expected result
- A recent successful backup, documented retention and a verified isolated restore exist. Required security updates and an accountable alert recipient are recorded.
- Warning signs
- Backup jobs report success without restore evidence, copies share the same failure domain, or security updates and alert ownership are unknown.
- What the evidence proves
- This operational checklist is not a vulnerability assessment. Patch level alone cannot establish that a previously compromised installation is clean.
- Next investigation
- Document recovery objectives and test a restore in isolation. Compare the exact Magento release with Adobe security guidance and the deployment’s dependency requirements.
- Verify recovery
- Record restore date, elapsed recovery time and application checks against the restored environment. Confirm an alert reaches the person responsible for responding.
Read the output, then challenge it
Worked example: “Ready” is only a starting point
Illustrative scenario—not a published customer incident. A product price was changed, but shoppers still see the old value.
Example observation A
catalog_product_price Ready Schedule idle (0 in backlog)
Example observation B
The same anonymous store-view page still shows the old price.Annotation: A says the indexer reports ready with no pending backlog in that snapshot. B says the business outcome is still wrong. Neither observation alone identifies the root cause.
- Scope: confirm product, website/store view, customer group, currency and applicable price rules.
- Evidence: compare the saved value and expected indexed result through approved access; check cron and recent indexing errors.
- Branch: if the indexed result is wrong, investigate indexing. If it is correct, trace application rendering, full-page cache and the CDN.
- Remediation: apply the narrow fix supported by the evidence. A blanket flush or reindex may hide the original cause.
- Verification: compare the same shopper context again, check the displayed price and confirm another planned update follows the normal path.
- Prevention: monitor processing and retain a small repeatable storefront verification routine.
A second example: queue:consumers:list can print consumer names while no worker is processing a required queue. The deciding evidence is completed work and queue age/depth, not the presence of a name.
Your evidence, organized
Build a developer handoff
Mark observations and add sanitized notes. Entries stay in this page’s memory and clear when you reload. No checklist entries are uploaded. Do not enter customer data, credentials or private endpoints.
Severity is an investigation priority, not an automatic diagnosis. A checkout failure takes priority even when other checks pass.
From a snapshot to a routine
Decide what must be checked continuously.
Manual investigation gives context. Repeated monitoring helps reveal changes between investigations. Define what matters, who receives an alert and how recovery will be verified.
| Area | Manual evidence | Health Guard catalogue coverage |
|---|---|---|
| Cron, indexers, cache | Configuration, execution, progress and storefront outcome | Status monitoring and environment diagnostics |
| Application incidents | Timestamp, recurrence and request correlation | Error Intelligence, incident grouping and operational history |
| Repeated observation | A schedule, owner and retained evidence | Pro scheduled monitoring and email alerts |
| Payments, inbox delivery and restore | Gateway reconciliation, mailbox checks, isolated restore | Not claimed as verified end-to-end coverage here |
This comparison reflects the published product catalogue, not an independent test of the extension. Confirm the current edition and configuration before relying on a specific capability.
Explore Buildmerce Health Guard →Monitoring should support your operational checks. Keep transaction verification, patch review and restore rehearsals in your runbook.
Common questions
Should I reindex everything during a health check?
Collect evidence first. Reindexing changes state and can add production load. Investigate the affected indexer, worker and dependencies before planning a targeted remediation.
Does a healthy homepage mean checkout is healthy?
No. Verify the customer path and reconcile the resulting order and payment state. A page response cannot establish the outcome of another operation.
How often should I run these checks?
Match frequency to order volume, catalog changes and incident risk. Use ongoing monitoring for recurring operational signals, plus focused verification after deployments and configuration changes.
Can I share the checklist with my developer?
Yes. Use Copy handoff or Download .txt. Add timestamps and sanitized observations, then assign an owner and next review date.
Sources & revision notes
Use the documentation matching your exact release and hosting model. The command references below are Adobe’s primary documentation.
- Adobe: Manage indexers ↗
- Adobe: Configure cron jobs ↗
- Adobe: Manage message queues ↗
- Adobe: Manage cache types ↗
- Adobe: Adobe Commerce system requirements ↗
- Adobe: Adobe security bulletins ↗
October 22, 2026 · First edition. Added ten observational checks, interpretation limits, a worked example and an interactive evidence handoff. An automated diagnostic script is not included in this release.
October 27, 2026. Added Magento category navigation and the supporting cron troubleshooting guide.