What is Session History in Onimator? Session History is the per-account log Onimator maintains for every session an account runs — what tools ran, what actions dispatched, how long the session lasted, what happened at the end. It’s the record you go to when an account behaves unexpectedly and you need to figure out what actually happened during the specific sessions you care about, instead of guessing from the current state.
The current state of an account tells you where it is now. Session History tells you how it got there.
What it records
Each session entry captures the operational data from that specific run. Timestamps for session start and end. Which tools ran and how many actions each dispatched. Which target accounts got touched. Any errors or interrupts that happened during the session. Whether the session completed cleanly or crashed partway through.
The detail level varies by tool and platform, but the core structure is consistent — one entry per session, chronological, per-account. You scroll through the history the same way you’d scroll through logs for a specific process, and you’re looking for either patterns or specific events.
What you actually use it for
Session History exists to answer diagnostic questions that current-state inspection can’t answer. Common ones:
Why did this account stop producing follows? Current state shows Follow Tool configured, Master Toggle ON, Timer Tab scheduling active. Session History shows the account’s last three sessions ended early because the platform served a Try Again Later popup. The tool isn’t broken. It’s being throttled and backing off correctly. Configuration change isn’t the fix — waiting is.
What did this account actually do in the last 24 hours? Reports and dashboards give aggregate counts. Session History gives you the specific timeline — 8 AM session ran Story Viewer and Like Tool, 11 AM session ran Follow and Comment, 4 PM session had a network interruption and ended after 6 minutes. Now you know whether the day’s actual activity matched your intent.
Why is this account’s Post Statistics showing failures? Failed publishes show up in Post Statistics as failed with an error code. Session History gives you the specific session context around each failure — was the account logged out, was the network flaky, did the account crash mid-upload. The error code alone doesn’t tell you which specific cause you’re looking at.
Did anything unusual happen during this specific window? If enforcement lands on an account, the first question is what the account was doing when it happened. Session History gives you the timeline for that specific window — which tools ran, at what volume, whether anything spiked outside normal patterns.
How it compares to Post Statistics and Stats Analyzer
Onimator has several reporting layers and Session History sits at a different level than the others.
Stats Analyzer gives you aggregate action counts across accounts and devices for a defined date range. Fleet-wide reporting for operational planning. Doesn’t tell you what specific sessions produced the numbers.
Post Statistics gives you per-post publish outcomes — which specific posts succeeded, failed, or are pending. Publish-focused. Doesn’t tell you what other tools were running during the same sessions.
Session History gives you the per-account, per-session record of everything the account did. Debug-focused. Not designed for aggregate reporting — designed for figuring out what happened on a specific account during a specific window.
All three surface useful data. Which one to reach for depends on the question you’re trying to answer. Aggregate performance question → Stats Analyzer. Publish-specific question → Post Statistics. “What actually happened on this account” question → Session History.
Retention and cleanup
Session History accumulates over time. On active accounts running daily sessions, the history grows fast — hundreds of session entries per account per month. Left unchecked, this data sits in the bot folder and takes up disk space, and the older entries stop being useful for debugging current behavior.
Onimator handles retention differently depending on version, but the general pattern is that older session entries either get automatically pruned or need manual cleanup. If you’re diagnosing recent issues, the recent history is what matters. If you’re doing historical analysis (which is rare), you’d want to export the data before it gets pruned.
Where it fits in the debugging workflow
When an account behaves in a way you don’t expect, the standard debugging sequence is:
Check current configuration (Master Toggle, Timer Tab, tool settings). If configuration looks right, check Session History for the account’s recent sessions. Look for patterns (sessions ending early, error codes, specific tools failing). Cross-reference against Post Statistics if the issue is publish-related, or Stats Analyzer if you’re comparing this account’s behavior to fleet norms.
Most per-account debugging traces back to something Session History shows if you look. Operators who don’t check it often spend hours guessing at causes that would have been visible in the log in seconds.
Related Terms
- Session — The unit of activity Session History records
- Stats Analyzer — The aggregate reporting layer that sits above Session History for fleet-wide performance analysis
- Post Statistics — The publish-focused reporting view that surfaces failures Session History can then explain