Activity Log
Auto-recorded per-test history: lifecycle events, edits, restores, scheduled starts/ends, and stop-condition trips. Live-updates and shows who did what.
Activity Log
Every meaningful state change on a test is recorded in its activity log — who did what, when, and (where it matters) why. The log is your built-in audit trail for collaboration and post-test reviews.
Otter A/B writes to the activity log automatically as the test moves through its lifecycle. You never have to remember to log anything — the dashboard captures transitions, edits, and automated decisions as they happen. The result is a per-test timeline you can scroll through to answer questions like “when did this go live?”, “who paused it?”, or “did this end because of a stop condition, or because someone hit Complete?”.
The log lives on the test detail page in a collapsible Activity section. Open it from the page itself, or use the timeline button in the test header to jump to it. The most recent 20 events are shown newest-first.
What gets logged
Lifecycle
createdThe test was created as a draft.updatedThe draft was saved with changes (linked to the version snapshot).startedSomeone clicked Start. Test went from draft to running.pausedSomeone paused the running test.resumedSomeone resumed a paused or completed test.completedSomeone clicked Complete. Test is finished.archivedA completed test was archived from the main list.restoredA draft was rolled back to an earlier version.
Automated
scheduled_startA scheduled start time arrived and the test auto-launched. No actor.scheduled_endA scheduled end time arrived and the test auto-completed. No actor.auto_stoppedA stop condition (visitor cap, conversion cap, or decision threshold) tripped. Metadata captures the reason.decision_threshold_reachedThe results crossed the configured decision threshold for the primary goal.
How to read an entry
- Actor. For user-driven events (lifecycle, edits, restores) this is the teammate's name. For automated events (scheduled starts/ends, auto-stops, decision-threshold) there's no actor and the dashboard shows the event as System.
- Action. One of the keys listed above. The dashboard renders these as friendly labels, but the raw key is what's stored.
- Timestamp. When the event happened, shown in your project's reporting timezone.
- Context. Some events carry extra info — the reason an auto-stop tripped, the scheduled time that fired, the version number that was restored, the summary of an edit. The dashboard surfaces the most useful pieces inline.
Using the activity log effectively
Use it during reviews. When you re-read a test's results, scroll through the activity log first. It reframes “the variant lost” into “the variant lost after someone paused it for two days mid-run.”
Pair it with Version History. Every “updated” entry links to the snapshot that captured what changed. If you're trying to figure out what a specific edit did, jump from the activity log into Version History to see the diff.
The log is the source of truth for “why did this end?”Manual Complete and auto-stop and scheduled-end all leave the test in the completed state — but the activity log makes clear which one actually fired.
Frequently asked questions
Quick answers to the questions teams ask most about this part of Otter A/B.