What are you trying to work out?

Seconds. Auditor subscribes to your store's events during installation, and the first change anyone makes afterwards should appear in the live feed almost immediately.

If the feed is still empty after ten minutes and someone has definitely edited something, open Settings → Recorded events and check the area is switched on. If it is, send us your store address.

Auditor has no view of your store's past. BigCommerce notifies us of events as they happen and does not provide a history to backfill from, so the record begins at installation. This is the main reason to install early even if you don't need it yet.

Read-only scopes for orders, products, customers, store settings and store information. Read access lets us fetch the current values so an entry can show what a field became, and lets us name the resource rather than just its ID.

Auditor requests no write scopes at all. It cannot change or delete anything in your store, which is also why it can't undo a change for you.

No. Auditor is not installed in your theme and runs no script on your storefront. Your store notifies our servers after an event has already completed, so nothing in the shopper's path waits on us.

Yes. Invite them under Settings → People with the Reviewer role. They can search, filter and export the log and nothing else — they cannot change Auditor's settings or see anything else in your BigCommerce admin.

Colour is consistent everywhere in Auditor: created something new exists, changed something was edited, and deleted something was removed or an attempt failed.

Once you know the three, you can read a screenful without reading the words.

The previous value is the field as it stood immediately before the change; the new value is what it became. On a price edit you would see $54.00 → $45.00. Use the previous value to put a mistake back — Auditor records it but cannot restore it for you.

Some events have no previous value because nothing existed before, such as a product being created.

BigCommerce attributes a change to whatever authenticated to make it. When another app, an integration or a script acts, the platform reports the app or token — not the person who started it. Auditor shows you which one, so your next step is that integration's own logs or the colleague who runs it.

Changes made by a person in the BigCommerce admin are attributed to their staff account.

Because BigCommerce doesn't send one for every event type. Auditor records the source IP wherever the platform provides it and leaves the field empty rather than guessing.

Usually not. Saving once in the admin can touch several fields, and BigCommerce reports some of them separately. Open both entries — the fields listed will differ.

Genuine duplicates are deduplicated on the event ID before writing, so if you find two entries with the same ID, that's a bug and we'd like to hear about it.

In this order:

• The date filter. It defaults to the last 7 days. Widen it.
• Retention. On Starter, entries older than 90 days are gone. Check the date against your plan's window.
• The area. Under Settings → Recorded events, confirm that area is on. A switched-off area records nothing while it's off, and turning it back on does not backfill.
• The event type. Not every action in BigCommerce emits an event. Bulk edits through some import tools report as a single API action rather than one event per row.

Still nothing? Send us the store address, the approximate time and what changed, and we'll trace it.

Yes, if the deletion happened while Auditor was installed and the products area was switched on. The entry names the staff account, app or token responsible, the time, and the product's field values as they were.

It cannot bring the product back. Export the entry and re-create it from the recorded values.

Almost always a delay in event delivery from the platform, which happens during large imports or a platform incident. Auditor stamps entries with the time the change occurred, not the time we received it, so your record stays chronologically correct even when delivery lags.

If we have an outage of our own, BigCommerce retries, and we backfill what arrives. Some events fall outside the platform's retry limit and cannot be recovered — see the limits of the record.

No, and that's deliberate. Entries are append-only: nobody can alter or remove one — not your staff, not your administrators, not ours. An audit log you can quietly correct isn't worth keeping.

If an entry is genuinely inaccurate, that's a fault in how we recorded the event. Report it and we'll investigate.

Start with three: repeated failed sign-ins, payment or tax setting changes, and bulk deletions. They are rare in a healthy store, which means each one is worth reading.

Resist switching everything on. An alert that fires forty times a day teaches your team to ignore alerts.

Raise the threshold under Settings → Alerts → Inventory, and exclude the integration that does your stock sync. Alerts on a scheduled sync are noise — the sync is supposed to change stock.

Check the recipient address under Settings → Alerts, then your spam folder, then whether your plan's recipient limit is already used up. Alert delivery status is shown next to each recipient — a bounced address is marked there.

Webhook and SIEM forwarding is on Enterprise. If you're on Growth and need it, tell us what you're forwarding to — it helps us prioritise.

Exactly the rows your filter shows, with every field of each entry — event, time, actor, resource, previous value, new value, IP where present. The PDF prints the filters and the date you ran it on the first page, so a reviewer can see what they're looking at.

Anything over about 50,000 rows is prepared in the background and emailed to you when it's ready — you can close the tab. If nothing arrives within an hour, tell us.

Entries older than the new plan's window stop appearing, but we hold them for 30 days before deleting them. Export what you need in that window, or move back up and everything reappears.

Yes, in two ways: add extra retention in 12-month blocks, or schedule an export on Enterprise so entries land in your own storage before they age out of ours. Either way, decide what retention period you can justify to your own auditor first.

With BigCommerce. App subscriptions are billed through your store account, so Auditor appears on your BigCommerce invoice and we never see your card. Anything we can help with goes to billing@auditorapp.com.

We keep recording — your record never gets a hole in it because of billing. You'll see a notice at 80% and again at 100%, and we email you once. Nothing is charged as an overage without telling you first.

Uninstall Auditor from your store's App Store area. Our access to your store is revoked immediately and the next payment stops. Your history stays downloadable for 30 days, then it's deleted. Want it gone sooner? Ask at privacy@auditorapp.com.

No. A record of changes is often something an auditor wants to see, but no app makes you compliant on its own. Whether your record satisfies a particular standard is a judgement for your auditor and your own advisers.

What Auditor does give you is evidence to show them, and export formats built for it.

In many places, yes — monitoring employees without notice can be unlawful, and it's your obligation rather than ours. Tell your team what's recorded and how long it's kept, and cover it in your own privacy notice. See clause 6 of the terms.

You decide, because you're the controller of that history and we only process it for you. Weigh their request against why you keep the record. If you decide entries should go, write to privacy@auditorapp.com with the specifics and we'll action it and confirm in writing.

Please tell us privately at security@auditorapp.com before anywhere else. We acknowledge within two business days and we won't pursue researchers acting in good faith.