Key takeaways
- Notifications are raised for employees idle or offline over 2 hours, devices not reporting over 2 hours, and sessions auto-closed past midnight.
- Each problem is raised once, so one outage does not flood the list.
- Read state is kept separately for each administrator.
If you have to check a dashboard every hour to know whether something is wrong, the tool is creating work instead of removing it. Alerts exist so administrators can act on exceptions. The trade-off is volume: too many notifications and people stop reading them.
The four notifications
Employee idle: idle for over 2 hours while punched in
Employee offline: offline for over 2 hours while punched in
Device not reporting: no response for over 2 hours while the employee is punched in
Employee auto punched out: a session was still open past local midnight and was closed automatically
Designed not to repeat
The platform checks for problems in the background every few minutes. When it finds one, it creates a notification once, so the same outage never produces a second alert. Administrators see a Notifications bell in the dashboard, and new notifications are pushed to it as they are raised. They can mark them read one at a time or all at once, and read state is kept per administrator, so one person's inbox never changes another's.
Why the midnight notification matters
A forgotten punch-out can quietly inflate a timesheet. When a session is still open past local midnight, it is closed automatically and an administrator is told, so the record stays accurate. Local midnight follows your organization's timezone.
What a notification contains
A notification describes the signal, such as idle time or a silent device. It never includes screenshots or keystroke content.
Read more on the alerts and notifications page.