Magento 2 maintenance: what to check every month

A Magento store rarely breaks in one day. It drifts: a missed patch, a module that falls behind, a backup nobody has tried, a log that slowly fills the disk. An hour once a month catches most of it. This is the list we work through, in order.

1. Security patches

Adobe publishes its security bulletins for Adobe Commerce and Magento Open Source on its security bulletin page, usually on the second Tuesday of the month. Check what is new, then check where your store stands.

• Your exact version: bin/magento --version. Compare it with the latest patch release for your line, not only the latest Magento.
• Isolated patches: Adobe’s Quality Patches Tool lists the official patches and shows which are applied (vendor/bin/magento-patches status).
• Anything urgent, like PolyShell (CVE-2026-48356), goes in on a copy first, then live the same week.

2. PHP

Check the PHP version your web server runs, not only the command line, because the two can differ. PHP has its own security releases, and some of them matter more than any Magento patch: php2shell in October was one. PHP 8.2 reaches end of life on 31 December 2026, so a store still on 8.2 should plan its next step now.

3. Modules

• composer outdated shows which modules have newer versions. Read the vendor’s changelog for security fixes before you update.
• Remove modules you no longer use. A disabled module is still code on your server.
• Note which modules hold you back from the next Magento version. That list decides how big your next upgrade is.

4. Admin access

• Go through the admin users and remove the ones that should not be there any more: old staff, old agencies, test accounts.
• Keep two-factor authentication on for every admin. Magento 2.4 ships with it.
• Check integrations and API tokens. If nobody knows what one is for, find out, then remove it.

5. Backups you have restored

Database, media and code, kept somewhere other than the store’s own server. Once a quarter, restore them on a copy and open the store. Most backup problems are found on the day you need the backup.

A backup you have never restored is a hope, not a backup.

6. Signs of a break-in

• New PHP files in pub/media or pub/static. Those folders should hold images and assets, never code.
• Files that are not in Git: git status on the server should show nothing you did not change.
• Scripts you did not add in the admin: Content → Design → Configuration (HTML head and footer) and your CMS blocks. Card skimmers often hide there.
• Cron jobs and admin users you did not create.

7. Logs, cron and indexers

• var/log/exception.log and system.log: new errors since last month, and how big the files are.
• Cron: if it stops, emails, indexing and scheduled prices quietly stop with it.
• bin/magento indexer:status: every indexer valid, and set to Update by Schedule on a busy store.

8. Speed and disk

Open the home page, a category, a product and the checkout, on a phone. Compare with last month: stores rarely get slow in one day, they get a little heavier every month. Check free disk space and the size of the database too; a full disk takes a store down faster than most attacks.

9. Write it down

One short note: the versions, what you updated, what you found. Next month starts from it, and the day you plan an upgrade, it is the first page you read. When the note says you are on 2.4.6, read what the end of its standard support means and the 2.4.9 upgrade checklist.

Where to start

If you would rather not do this every month, our Magento 2 support plans cover this list, with checks every few minutes in between. If you are not sure where your store stands today, our free audit goes through the list once and tells you what to fix first.

Sources: Adobe’s security bulletins for Adobe Commerce, the Quality Patches Tool guide on Experience League, and PHP’s supported versions page on php.net, checked on 5 November 2026.