General FAQs

1.Supported Linux distributions and versions

The agent works best on Debian and Ubuntu, which are our primary, fully-tested platforms. We also support RHEL/CentOS/Fedora-family systems, though that path has had less testing so far.

On the desktop side, the agent automatically detects and configures itself for the two most common environments, GNOME and KDE. If your users are on other setups like XFCE, Cinnamon, or i3, the agent won't auto-configure and will flag that it couldn't detect the environment, so those would need a closer look before rollout.

One more thing worth flagging: the agent runs on X11. If a machine is using Wayland, the agent will automatically switch it over to X11 the next time the user logs in, so no manual setup is needed there.
If it helps, we're happy to review your specific fleet's distributions and desktop environments up front so there are no surprises during deployment.

2.Typical RAM and CPU usage

Under normal operating conditions the agent is lightweight across all supported platforms:

Windows

• RAM Usage: ~50 MB (basic tracking); temporary spikes to 100-200 MB when screenshots are enabled
• CPU Usage: ~1-2%
• Installation Size: <100 MB

Linux

• RAM Usage: ~60 MB
• CPU Usage: Minimal
• Installation Size: <150 MB

Mac

• RAM Usage: ~60 MB
• CPU Usage: Minimal
• Installation Size: <250 MB

This footprint is designed to avoid the machine slowdown experienced with your earlier application.

3.Sync frequency and performance impact

Activity is captured on every tab or window switch. Timesheet data syncs to the server every 5 minutes when an active internet connection is available.

The performance impact is minimal, consistent with the RAM and CPU figures above. If work happens offline, data is retained locally and sent in batches once connectivity is restored. This may make the sync slightly slower to catch up, but no data is lost.

4.Weekly offs and public holidays configuration.

Both weekly offs and public holidays can be configured at the company level, team level, and individual level, giving you full flexibility rather than a global-only setting.

5.Retroactive reclassification of activity.

Currently, when a website or application is marked productive, the change applies only to new (going-forward) activity; historical data is not reclassified.

This is a deliberate design choice: we maintain audit-log integrity on these classifications, and retroactive back-dating would undermine that. It also prevents data from being distorted when a user's role or responsibilities change over time. That said, retroactive reclassification can be built with a short development cycle if it's a requirement for your deployment.

6.Real-time synchronization, delays, and offline scenarios

Activity capture happens continuously on every tab or window switch, with timesheet sync occurring every 5 minutes on an active connection (as covered in point 3). The architecture is robust and designed so that no data is lost.

In offline scenarios, data is queued locally and transmitted in batches when connectivity resumes, so there may be a short catch-up delay. Unlike your previous vendor's experience, activity is not dropped or indefinitely delayed; it is reliably reconciled once the machine is back online.

Updated on: 29/07/2026