What is Time Manager? Time Manager is the OniHelper Suite’s bulk schedule allocator — a dedicated tool that takes a device-level runtime window and an allocation method as input and calculates per-account Start and End times for every account on the selected device(s), then writes those times directly to Onimator’s database so the bot’s Timer Tab picks up the new schedule automatically. Rather than opening each account in Onimator and setting Start/End hours one-by-one, the operator specifies the daily window once and picks a distribution strategy, and Time Manager works out the specific per-account slots that fit inside the window without overlap. It exists specifically to solve the multi-account-per-device scheduling problem: how do you divide a 24-hour day across multiple accounts on the same phone without them running simultaneously, which is one of the specific patterns detection systems treat as a botnet tell.
Why Staggered Scheduling Matters
The specific reason Time Manager exists at all is that multi-account-per-device setups produce a detection risk that single-account devices don’t face. When two or more accounts on the same physical or emulated device run automation simultaneously, their outbound activity produces the specific signature that reads as coordinated automation from one hardware source — parallel session activity, identical device fingerprints attached to concurrent actions, and the specific timing patterns that detection systems recognize as one operator running multiple accounts from one machine.
Real users don’t produce this pattern. A person using multiple accounts on one phone switches between them serially — they open one account, use it, close it, and then open the next. The specific behavioral pattern is sequential rather than parallel, and platforms’ detection models are tuned to expect that pattern from ordinary multi-account users. Onimator’s Timer Tab handles per-account scheduling that produces this serial pattern, but the operator has to set each account’s Start and End times manually — which becomes impractical as soon as more than a handful of accounts share one device.
Time Manager solves the specific math problem the operator would otherwise have to solve manually. Given a device runtime window and account count, it calculates the per-account slots that fit without overlap and writes them to the bot’s configuration in one action.
How Time Manager Works
Time Manager runs as a dedicated tab in the OniHelper Suite. The operator points it at the Onimator bot folder to populate the device list, picks either Single Device mode (one phone) or Multiple Devices mode (many phones at once), selects the specific device(s) to schedule, sets the daily runtime window (Start Time and End Time), picks the allocation method, and clicks Apply Time Settings to commit the calculated schedule to Onimator’s database.
An Accounts table at the bottom of the tab shows every account on the selected device(s) with Current Start Time, Current End Time, New Start Time, and New End Time columns. This diff view lets the operator see exactly what’s about to change before committing, which is one of the specific safeguards Time Manager provides against pushing wrong schedules across many phones by accident.
The Three Allocation Methods
Equal Distribution splits the day evenly across accounts on the device. Four accounts sharing a 24-hour window get 6-hour slots each, running back-to-back. This produces steady, predictable per-account throughput and suits strategies where each account should run one long daily shift.
Sequential (One after another) produces mathematically similar results to Equal Distribution but frames the allocation as a strict queue — account A finishes, then B starts, then C. It suits strategies where the hand-off between accounts should be explicit.
Round-Robin (Multiple rounds per day) is different in structure and typically the most useful for human-realistic behavior. Instead of giving each account one long daily slot, Round-Robin gives each account several short windows spread across the day. A device online for 12 hours with Rounds Per Day set to 4 and Minimum Account Runtime set to 30 minutes gives each account roughly four 30-minute windows distributed through the day. This produces the check-multiple-times-per-day pattern real users generate rather than the run-one-long-shift pattern automation would otherwise produce, which is one of the specific behavioral variables that distinguishes accounts that survive long-term operation from accounts that get caught by pattern-analysis detection.
Minimum Account Runtime
A Minimum Account Runtime floor prevents the allocator from chopping the device window into slots too short to produce meaningful work. The default is 10 minutes, but well-configured deployments typically set this to 15 minutes or higher because shorter slots waste the runtime budget on app startup overhead without leaving enough time for actual operational activity. When the allocator can’t satisfy the minimum for every account within the configured window and rounds count, it produces the specific error state where the New Start/End columns come back blank, which is Time Manager telling the operator the requested configuration is arithmetically impossible.
Templates and CSV Export/Import
Save as Template and Import Template let operators reuse a proven allocation configuration across new device sets rather than reconfiguring from scratch every time. For fleets that onboard new phones or accounts on a recurring basis, templates lock in the operator’s house allocation and make provisioning new devices a one-action commit rather than a multi-step configuration exercise.
Export to CSV and Import from CSV support both backup and migration. Before pushing a new allocation across many devices, Export to CSV creates a backup of the current schedule that can be restored if the new allocation produces problems. Import from CSV supports moving allocations between Onimator installs or restoring previously-exported states.
Where Time Manager Sits in the Onimator Stack
Time Manager is one of the specific OniHelper Suite tools that closes the gap between Onimator’s single-account UI and the operational reality of running fleets with multi-account-per-device configurations. Onimator’s Timer Tab handles per-account scheduling correctly, but the tab is designed for one-account-at-a-time editing. Time Manager treats scheduling as a fleet-level operation that produces coordinated, non-overlapping slots across all accounts on all selected devices in one action.
The tool writes directly to the same per-account Timer Tab fields Onimator already uses, which means the schedules Time Manager produces are indistinguishable from schedules an operator would have set manually one account at a time. Onimator runs to the new schedule automatically on the next session cycle without any additional configuration.
Why It Matters for Automation
Time Manager is the specific mechanism that makes multi-account-per-device configurations survivable at scale. Without it, operators either accept the manual burden of per-account schedule editing (impractical past a few devices) or skip staggered scheduling entirely and accept the parallel-execution detection risk (produces predictable enforcement). With it, staggered scheduling scales to fleets of any size and Round-Robin patterns produce human-realistic behavior automatically. Skipping this tool for multi-account deployments is one of the specific configuration mistakes that produces the botnet-signature enforcement that shortens fleet operational lifespan.
Related Terms
- Multi-Account Management — The broader operational discipline Time Manager serves for scheduling coordination
- Tag Manager — The sibling OniHelper Suite tool that handles fleet organization on the tagging dimension
- Behavioral Baseline — The specific detection signal Round-Robin scheduling helps establish for multi-account-per-device configurations