Activity logs: knowing who changed what

A member writes to say her renewal price went up without warning. Your assistant is sure she did not change anything. Your developer says he only touched the theme. Somebody changed the price on that plan, but without a record you are left with guesswork, awkward conversations and a refund you are not sure you owe.

An activity log, sometimes called an audit trail, is a record of actions taken in a system: who did what, when and often from where. Most membership software and the services around it keep some kind of log. Knowing where those logs are, what they capture and how to read them turns a mystery into a five-minute check, and makes a security incident far easier to investigate.

What a useful log entry tells you

A good log entry answers five questions:

• Who: which named account performed the action. This is why shared logins cause so much trouble; a log that says “admin” tells you nothing.
• What: the action itself, such as changed a price, exported members, deleted a lesson or added an administrator.
• When: the date and time, including which time zone the log uses.
• Where from: often an internet address, rough location or device, which helps you spot a login that did not come from your team.
• Before and after: the best logs record old and new values, so you can see that a price went from one amount to another, not just that it changed.

Where your logs live

There is rarely one log. The picture of what happened is usually spread across several services:

• Your membership platform: admin actions, member logins, level changes, content edits and exports, depending on what your software records. Check its settings, because some logging is switched off by default or kept only briefly.
• Payment processor: refunds, payout detail changes, new team members, connection keys created and edits to plans or prices.
• Email marketing service: campaigns sent, list imports and exports, and changes to automations.
• Business email: sign-in history, new devices and changes to forwarding rules.
• Hosting, domain registrar and DNS: logins and configuration changes.
• Community tools: moderation actions, such as posts removed and members suspended.

Make a short list of where each log is found and how long each service keeps it. Some keep records for years; others only for a few weeks, which matters if a problem is noticed late.

Keep your own change log for everything else

Not every change leaves a trace in a system log. A decision made in a meeting, a setting your host changed at your request, or an edit your platform does not record can all vanish. A manual change log fills the gap. It is simply a shared document where anyone making a significant change adds a line:

Date and time. Who. What changed: raised the price of the annual plan for new sign-ups only; existing members unaffected. Why: agreed at the planning meeting. Where: payment processor and pricing page. How to undo: restore the old price in both places.

Use it for prices, plan settings, email automations, redirects, DNS changes and anything else that affects what members see or pay. If you already keep a record when you update your platform and add-ons, combine the two.

What to look for in a regular review

Logs only help if someone looks at them. You do not need to read every line. A short monthly review should scan for the actions that matter most:

1. New administrators or changes to anyone’s permissions.
2. Exports of member data, and who ran them.
3. Changes to payout or payment settings.
4. Logins from unfamiliar places or devices, or at hours when nobody on your team works.
5. Bulk actions, such as many members deleted, many posts removed or a large email send.
6. Security settings switched off, such as two-factor authentication removed from an account.

Where a service can alert you to any of these as they happen, turn the alerts on. An instant alert about a payout change or a new admin is worth far more than a log you read weeks later.

A worked example: the mystery price change

A hypothetical community theater association sells memberships at three levels. One morning, Lucia, who runs it, receives two complaints that the supporter level has renewed at a higher price. Here is how she traces the cause:

1. She opens the payment processor’s log and filters for changes to the supporter plan. It shows a new price created a week earlier by the account of her part-time administrator.
2. She checks the manual change log. The administrator had noted: “Created new supporter price for next season’s sign-ups.”
3. She checks the membership platform’s log and sees that, a few minutes later, the plan was switched to the new price for all members, not just new sign-ups.
4. She talks to the administrator, who realizes she picked the wrong option. Nobody did anything malicious; the setting had a confusing label.

Lucia restores the old price for existing members, refunds the difference to those affected and adds a rule to her written procedures: price changes are made by one person and checked by another. The investigation took twenty minutes because the logs existed and named real people.

Logs are personal data too

Activity logs often include member names, internet addresses and login times, so treat them with the same care as the rest of your member information. Limit who can view them, keep them only as long as they are useful for security and troubleshooting, and mention in your privacy policy that you keep records of account activity. How long is appropriate depends on your needs and on the rules that apply to you.

Your next steps

1. List every service that keeps an activity log and note how long it keeps records.
2. Switch on any logging your membership platform offers but has turned off.
3. Make sure every person has their own named login, so the logs mean something.
4. Start a manual change log and share it with your team.
5. Turn on alerts for new admins, exports and payout changes.
6. Put a short monthly log review in your calendar.