Magento Admin Audit Logs: Answering "Who Changed This?"
Magento 2 Open Source does not include Adobe Commerce's Action Logs report. If someone changes a price, disables a product or edits a CMS block, there's no comparable native record of who did it, when, or what the value was before. A useful audit log answers "who changed this?" by recording the admin user, timestamp, IP address, object affected and before-and-after values. That last part - the old value as well as the new - is what turns a log from a curiosity into an investigation tool.
Does Magento 2 log admin changes by default?
Not in the same way. Adobe Commerce includes an Action Logs report for enabled admin actions, while Magento Open Source does not include that report. Open Source therefore has no comparable native record for a product edit, price change, configuration toggle or CMS block rewrite, and no built-in before-and-after view for those changes.
That gap stays invisible right up until the moment you need it. Everything's fine until a customer emails asking why a product they bought last week is now double the price, and you open the product and find a value nobody remembers setting - with no way to tell whether it was a person, an import, or an integration that did it.
What should a proper audit log record?
Five pieces of information turn "something changed" into "here's exactly what happened". Miss any one and the log gets noticeably less useful.
| Field | Why it matters |
|---|---|
| User | Accountability. Which admin account made the change - and if it's a shared login, that's its own finding. |
| Timestamp | Correlate the change with a support ticket, a deploy, or a sales dip. |
| IP address | Distinguishes a staff member in the office from a compromised account signing in from elsewhere. |
| Object | What was touched - which product, which config path, which CMS block. |
| Before and after values | The old value and the new. Without the old value you know something changed but not what it was, so you can't undo it confidently. |
The changes that cause the most "who did this?" moments
A few kinds of change generate nearly all the frantic Slack messages. Each is a case where a log with before-and-after values ends the guessing immediately.
- A price changed. A product is suddenly cheaper or dearer than it should be. Was it a person, a bulk update, or a feed? The old value tells you what to restore.
- A product was disabled. It's gone from a category and support is fielding "where did it go" emails. A log shows who set it to disabled and when.
- A shipping method changed. Free shipping is suddenly on everywhere, or a rate is wrong at checkout. Config changes rarely announce themselves.
- A coupon was misconfigured. A code that should give 10% is taking 100%, or has no usage limit. Minutes matter, and you need to see the exact rule that changed.
- A CMS block was edited. The homepage banner is broken or shows old copy. Who last saved that block, and what did it say before?
- An admin user was added. This is the security one. An unexpected new admin account is a red flag, and you want to know who created it and from where.
How long should you keep audit logs?
Long enough to investigate, short enough not to bloat the database. AuditEasy's ceiling is 7 days on Seed, 30 days on Growth and 365 days on Pro, so choose the longest window your risk and plan justify. Audit logs record every attribute change, so on a busy store they add up fast, and an unbounded log is a database-size problem waiting to happen.
The judgement call is between forensic value and storage. If you're in a regulated context or want a longer paper trail, keep more; if you just want to catch operational mistakes, a rolling month or two is plenty. What matters is that retention is a deliberate setting, not an accident - either logs are pruned on a schedule you chose, or they grow forever, and you should know which.
How this applies to Magento 2
On Magento Open Source, an audit trail is something you add, not something you configure. Because the platform doesn't record admin changes with before-and-after values, you're choosing between building a custom logging layer - observers on model save and delete events, capturing old and new values, tied to the admin session and IP - or installing a module that does it. The custom route is deceptively large: catching every entity type, storing per-attribute old and new values, joining changes back to the login that made them, and pruning old records all have to be built and maintained.
Where Moogento helps
AuditEasy adds the audit trail Magento Open Source leaves out. It keeps two logs. The access log records every admin login and logout - successful and failed - with the username, IP, an approximate location resolved from that IP, the browser, and the session. The action log records changes across the admin: products, prices, categories, system configuration, CMS pages and blocks, cart and catalogue price rules, email templates, admin users and more. Every logged change ties back to the login session that made it, so user and IP are always attached, and every changed attribute is stored with its old value and its new value - the before-and-after that makes a log actually usable. The grids live under a dedicated AuditEasy menu in the admin, filterable by user, entity type and action, and exportable to CSV.
A couple of specifics are worth knowing. Retention is a plain "keep for N days" setting under Stores > Configuration > Moogento > AuditEasy, and the cleanup cron removes records older than the effective value. The plan ceiling is 7 days on Seed, 30 days on Growth and 365 days on Pro; set zero only if you deliberately want no scheduled pruning. Failed admin logins are recorded when Admin Access logging is enabled, and the Security: Notifications group can send critical warning emails for multiple failed attempts, new login locations and changed login patterns. That is an early warning for a brute-force attempt, not a replacement for the wider Magento admin security checklist. Finally, AuditEasy is an admin action and access trail, not an order-status history. If what you're after is the operational picture - sales, traffic and campaign performance rather than who edited what - that's a different job, and Pulse is the Magento-native dashboard for it.
Audit trail setup checklist
- Confirm what you have today: on Magento Open Source, assume you have no before-and-after change log until proven otherwise.
- Decide which changes you most need to trace - price, product status, config, coupons, CMS, admin users cover most incidents.
- Make sure the log captures all five fields: user, timestamp, IP, object, and both old and new values.
- Check that changes tie back to a named admin account. Shared logins undermine the whole trail - give each person their own.
- Set a deliberate retention window within your plan's ceiling and confirm old logs are actually pruned.
- Turn on alerting for repeated failed admin logins and for new admin user creation.
- Test it: change a test product's price, then find that change in the log with its old value. If you can't, the trail has a gap.
FAQ
Does Magento 2 record who changed a product or price?
Not with the native Action Logs report. Adobe Commerce includes that report, but Magento Open Source does not, so Open Source merchants need a custom logging layer or an extension such as AuditEasy to answer "who changed this?" for product, price, configuration and CMS changes.
Why do before-and-after values matter in an audit log?
Because the new value alone only tells you something changed, not what it was. Without the old value you can't confidently restore the correct setting - you're guessing. A log that stores both lets you see a price went from £49.99 to £4.99 and put it back exactly, rather than trying to remember what it should be.
How long should Magento audit logs be kept?
Choose a window that matches the store's risk and the plan ceiling. AuditEasy supports up to 7 days on Seed, 30 days on Growth and 365 days on Pro, with scheduled pruning of older records. Audit logs record attribute changes, so they grow quickly on busy stores. Make retention a deliberate setting rather than letting logs accumulate forever.
Can audit logs help an agency managing client stores?
Yes, and it's one of the strongest cases for them. When a client asks why something changed, a log with user, timestamp and before-and-after values answers "was it us or you?" in seconds instead of an awkward back-and-forth. It also protects the agency by giving a clear record of what was and wasn't touched.
Change a test product's price and then go find that change - with its old value - in whatever logging you have. If you can't, you don't have an audit trail yet, and the next "who changed this?" will be answered with a shrug instead of a screen.
