# Magento Admin Audit Logs: Track Every Change in the Admin ![Magento admin audit logs editorial hero](images/magento-admin-audit-logs.webp) ## Overview Magento Open Source does not keep an admin audit log. It records that admin sessions and login attempts happened, but it never records what an admin actually changed, so when a price is wrong or a setting flips there is no built-in way to see who did it or when. Adobe Commerce ships an Admin Actions Log (the `Magento_Logging` module, under **System > Action Log**); Open Source does not include that module at all. On a standard Open Source store, the change history you need for accountability, security forensics, and compliance simply is not being written down. **Key point: Open Source logs admin sessions and failed logins, never the content of a change, so "who edited this?" has no native answer without a third-party audit module.** --- ![Store manager reviewing an admin activity trail on screen](images/magento-admin-audit-logs-lifestyle.webp) ## What does Magento Open Source actually log about admins? Open Source records a few narrow signals, all of them about access rather than change. Failed and successful admin logins are tracked. The `admin_user` table carries `failures_num`, `first_failure`, and `lock_expires`, which drive the lockout you configure under **Stores > Configuration > Advanced > Admin > Security** (six failed attempts locks the account for thirty minutes by default). The `Magento_Security` module keeps an `admin_user_session` table with the user, status, IP address, and timestamps, plus a `password_reset_request_event` table logging reset requests by IP. That is the whole picture. There is no record of a product being re-priced, a tax rule being edited, a CMS block being rewritten, a customer group being changed, or a config value being toggled. The application also writes to flat files in `var/log/` (`system.log`, `exception.log`, `debug.log`), but those capture errors and developer traces, not a human-readable trail of admin edits. ## Why does an admin audit trail matter? An audit trail answers one question that comes up constantly in a real store: who changed this, and when? - **Accountability.** When a price drops to a penny or free shipping goes live by mistake, you need to know which admin account made the edit and what the value was before, so you can fix the cause rather than argue about it. - **Security forensics.** If an admin account is phished, the first thing you want is a timeline of what that account touched. Session and login records tell you someone logged in; only a change log tells you what they did once inside. - **Compliance.** Audit-trail requirements sit inside PCI DSS and ISO 27001. Both expect you to track and review changes to systems that handle cardholder or personal data. Open Source cannot produce that evidence on its own. - **Debugging.** Half of "the store suddenly broke" tickets are a config or catalogue change nobody remembers making. A change log turns a two-hour investigation into a ten-second lookup. --- ## What should you track in a Magento admin? Not everything is worth logging. Focus on the actions that carry money, access, or customer data. ### Step 1 - Log admin logins and logouts Record every login and logout with the account, IP address, and browser. This is your first signal of a compromised credential: a login from a new country at 3am is worth an alert on its own. ### Step 2 - Log configuration changes Config edits under **Stores > Configuration** change how the whole store behaves. Payment settings, tax, shipping, and security options all belong here. Capture the config path, the old value, and the new value. ### Step 3 - Log product and price edits Price, special price, stock status, and status (enabled/disabled) are the fields most likely to cause a visible incident. Track them with before-and-after values so you can see that a price went from 49.00 to 4.90, not just that "a product was saved". ### Step 4 - Log order edits Order status changes, comments, refunds, and address edits touch money and fulfilment. A trail here protects you in payment disputes and internal fraud checks. ### Step 5 - Log user and role changes Creating an admin user, changing a role's permissions, or resetting an API token is high-risk by definition. These changes decide who can do everything else, so they deserve the closest watch. --- ## Common mistakes when setting up admin logging ### Mistake 1 - Assuming Open Source has an action log Many teams believe the Adobe Commerce **System > Action Log** exists everywhere. It does not. The `Magento_Logging` module is a commercial-edition feature, so on Open Source the menu item is simply absent and no change history is being written. ### Mistake 2 - Relying on `var/log` files as an audit trail The flat log files rotate, get wiped on deploys, and record errors rather than edits. They are useful for debugging, but they are not an audit trail and they will not tell you who changed a price. ### Mistake 3 - Sharing one admin account If the whole team logs in as a single account, every log line points at the same user and the trail proves nothing. One human, one account, is the rule that makes any audit log worth keeping. ### Mistake 4 - Logging everything and reading nothing A log that captures every field on every save becomes noise nobody opens. Track the high-value actions, alert on the risky ones, and keep the rest for on-demand lookups. --- ## Advanced: retention, alerts, and reverts A change log becomes far more useful once you add three things on top of it. - **Retention.** Decide how long you keep history. Thirty days covers most day-to-day questions; a year is closer to what a compliance auditor expects. Longer retention costs storage, so match it to your obligations rather than keeping everything forever. - **Alerts.** The highest-value events should push, not wait to be found. A new-location admin login, a data export, or a change to a payment setting is worth an email the moment it happens. - **Revert.** The gap between "I can see what changed" and "I can put it back" is large. Being able to restore a single field from the log, without editing the database by hand, turns an audit tool into a recovery tool. --- ## Where Moogento Fits Because Open Source has no action log, adding a real audit trail means installing a module that records changes at the attribute level. [AuditEasy](https://moogento.com/auditeasy-m2) does exactly that: it captures every admin login and logout with IP and browser, and every product, price, category, CMS, customer, and configuration change with the before-and-after values and the user responsible. It adds email alerts for failed logins, new-location logins, and data exports, an in-page changelog tab on product and customer forms, and the ability to revert a single field or a whole save without touching the database. Retention is configurable so you can match it to a compliance window rather than guessing. It does not replace patches, 2FA, or a short admin-user list. It fills the one gap the platform leaves open: the record of what actually changed. --- ## Real-World Impact Stores that add a proper admin audit trail typically find: - Incident investigations that used to take hours end in a single lookup, because the change and the account behind it are both recorded. - Accidental price and catalogue changes get caught and reverted the same day instead of running live for a week. - Compliance reviews get easier, because the "who changed what" evidence exists and can be exported. The value is not the log itself. It is the questions you can finally answer with it. ## FAQs ### Does Magento Open Source have an admin audit log? No. Magento Open Source records admin sessions and failed logins, but it does not log the content of admin changes. The Admin Actions Log under **System > Action Log** is part of Adobe Commerce (the `Magento_Logging` module) and is not included in Open Source. ### How do I see who changed a price in Magento? You cannot see who changed a price on standard Magento Open Source, because no change history is stored. You need a third-party audit module that records product and price edits with before-and-after values and the admin account responsible, or you need Adobe Commerce with its Action Log enabled. ### What does the admin_user table track in Magento? The `admin_user` table tracks login failures through the `failures_num`, `first_failure`, and `lock_expires` fields, which power the account lockout configured under **Stores > Configuration > Advanced > Admin > Security**. It does not track what an admin edited after logging in. ### Where are Magento admin logs stored? Magento writes error and debug logs to flat files in `var/log/` (such as `system.log` and `exception.log`). These are developer logs, not an audit trail, and they rotate and can be cleared on deploys, so they should not be relied on for accountability. ### Is an admin audit log required for PCI DSS? Audit-trail requirements sit inside PCI DSS and ISO 27001, which expect changes to systems handling cardholder or personal data to be tracked and reviewable. Open Source cannot produce that evidence natively, so stores under those obligations usually add an audit module. ### How long should I keep Magento admin audit logs? Match retention to your obligations. Thirty days answers most operational questions, while a year is closer to what compliance auditors expect. Longer retention costs storage, so choose a window rather than keeping everything indefinitely. ### Can I get alerts when an admin exports customer data? Core Magento Open Source cannot alert you when an admin exports customer data. A dedicated audit module can watch for export events, new-location logins, and failed-login patterns, and email you when they occur. That is the point at which a log becomes an early-warning system rather than a record you read after the fact. ## Next Steps - Confirm whether you are on Open Source or Adobe Commerce, since that decides whether any action log exists at all. - Give every admin their own account and remove shared logins. - Decide which actions matter to you: logins, config, prices, orders, and user or role changes. - Add an audit module that records attribute-level changes with revert, and set retention to your compliance window. The highest-value move is recording price, config, and user changes with before-and-after values, because those are the edits that cause visible incidents and the ones no native log will ever explain. Related reading: [Stop Magento Spam Sign-ups and Card-Testing Without CAPTCHA](magento-stop-spam-card-testing.md) and [Securing Magento 2](securing-magento-2.md).