Activity

The activity log shows every change people make in your store. Use it when a number moved and you want to know why, or when a record is in a state nobody remembers putting it in.

Litestore writes one Activity row for each change it logs.

Each row records four things. It stores the type of change and a description. It names the admin or customer who made it. It also links to the product, order or collab that was changed.

Insights → Activity reads from this one table. Each record's own timeline reads the same rows, filtered to that record. There's no separate history for each record that could drift away from the store-wide log.

You'll find the log here:

Insights → Activity
/admin/activity

You need the activity:view permission to open it.

What gets logged

Litestore writes an activity row for four kinds of change:

• Create
• Update
• Delete
• Duplicate

Every edit to a record passes through one shared layer in the code, and that layer writes the row. Individual screens don't have to remember to log anything. This is why the log covers the whole store consistently. A module can't forget to be logged.

Litestore also stores which fields changed, in the row's metadata field. An update row tells you what actually changed, not only that something did.

The default view

The log opens on the last 30 days and loads 100 items. Pinned rows appear at the top.

window     last 30 days
page       100 items
ordering   pinned rows first

Pinning helps you keep track of an investigation. A row you pin stays at the top while you change the filters around it.

Filters

You can narrow the log in four ways:

1. Module, such as orders, products, refunds, disputes, shipping rates, API keys, webhooks or settings
2. Activity type within a module
3. Date range
4. The specific admin, customer, product, order or collab involved

The fourth filter is the one that turns the log from a stream into an answer. If you filter to one order, you see every change anyone made to it, in order, no matter which screen they used.

Who did it

Each row names the admin or customer who made the change.

There's one exception. When the AI assistant carries out an action after you approve it, Litestore marks the row with an ai actor. The log shows it as "by AI", not as the admin who approved it.

That's intentional. You approved the action, but you didn't write it. If the log credited you with the assistant's work, it would mislead whoever reads it six months later.

Why a retry can't log twice

Some changes arrive through background jobs that promise to deliver an event at least once. That means an event can sometimes arrive more than once.

These changes carry a key that marks them as unique. If a background job retries, Litestore doesn't log the same change a second time.

Without this key, the log would count the troubled changes more than once. Those are exactly the changes you most need to see correctly.

Export

You can export the rows you're looking at to CSV.

The export follows your filters. If you narrow the log to one module and one date range first, you get only those rows, not the whole table.

Using the log

1. Start from the record if you know which one it is. Its own timeline shows the same rows, already filtered.
2. Use the store-wide log with a module filter when you suspect a pattern rather than a single incident.
3. Pin the rows that matter and export what you've found if you need to share it.

The log tells you who changed something and what it was before. If you want to know what a number is made of, use the Analytics page instead.

Related