A deploy that succeeded is not a store that is healthy
Deploy scripts report success when the commands finish, not when the store is actually working. Those are different facts, and the gap between them is where post-deploy incidents live.
A green deploy can still leave stale static content, a stopped cron, an invalid indexer, or a broken checkout. The only way to know is to verify the store itself, not just the pipeline.
This article is a verification checklist to run after every deploy, covering the state, the background systems, and the critical paths that decide whether the store really works.
Verify the state the deploy set
Start with the things the deploy was supposed to configure. These are quick to check and common to get wrong:
- Deploy mode is
production, confirmed withbin/magento deploy:mode:show. - Static content was redeployed and its version string changed, so browsers pull fresh assets.
- Compiled code in
generated/matches the deployed release. - Caches were flushed and are warming, not left cold on a busy store.
Each of these has bitten stores that deployed successfully. Confirming them takes a minute and rules out the most common post-deploy breakage.
Confirm the background systems
The storefront can look fine while the systems behind it are broken by a deploy. Cron and the indexers are the two to check every time.
Confirm cron is running by checking recent activity in cron_schedule, and confirm the indexers are valid with bin/magento indexer:status. A deploy that changed configuration or reset a service can leave either one stopped, and neither raises an alarm on its own.
Check the database and schema
If the deploy included an upgrade or a patch, the database state is part of verification. A schema change that did not fully apply is a problem you want to find now, not on the next deploy.
Run bin/magento setup:db:status to confirm the database matches the code. A report of pending changes means the upgrade portion did not finish, even if the deploy reported success.
This step matters most on release deploys and can be skipped on simple code-only pushes, but knowing which kind of deploy you ran is part of the discipline.
Watch the logs for new errors
A deploy can introduce errors that only appear under real traffic. The logs are where they show up first, so a short watch after deploy is worth the time.
Read exception.log and the web server error log for anything new since the deploy, ranking by frequency rather than reading chronologically. A signature that started at the deploy timestamp and is climbing is a regression the deploy introduced.
This is also where server-level failures appear that Magento's own log will not show, so checking both is part of a complete look.
Walk the critical paths
The final check is the one that matters most: does the store still do what it exists to do. Automated smoke tests are ideal, but even a manual walk catches the failures that infrastructure checks miss.
Add a product to the cart, complete a test checkout including payment, run a catalog search, and process a test order in the admin. These are the paths that generate revenue, and a deploy that broke one of them is an emergency regardless of how clean the pipeline looked.
A synthetic version of this walk, run automatically after each deploy, turns the most important check into one that never gets skipped under time pressure.
Keep the previous release ready
Verification is only useful if you can act on a bad result, which means the previous release has to stay ready to roll back to. A failed verification with no way back is just an earlier warning of the same outage.
That means keeping the prior code release available and a database backup from immediately before the deploy. For a code-only deploy, reverting the release is quick; for one that changed the schema, the database backup is what makes rollback real.
The discipline is to treat the deploy as reversible until verification passes. Only once the checks and the critical-path walk are clean is the new release truly the current one.
Make verification part of the deploy, not an afterthought
The point of a checklist is that it runs every time, not only when someone remembers. The best version is automated: mode, cron, indexers, schema, logs, and a smoke test, checked as the last stage of the deploy itself.
Knowing the store is verified healthy after each deploy, rather than assuming it because the pipeline was green, is what turns deploys from a source of incidents into routine events. Building that verification habit is a practical outcome of any stability-focused platform review.