In browser monitoring, sessions, alarms and individual call attempts are shown separately. Review them together when investigating a session with a missed check-in. An alarm ending does not mean the session has ended or confirm that the worker is safe.
Prerequisites and opening monitoring
The organization must have work alone protection enabled. Managers and local administrators can view sessions, alarms and call attempts, and stop a session in the browser. The worker must first start their own session in the mobile app; simply assigning a user to a configuration does not start a session.
Open Work Alone Protection Monitoring from the browser menu. The page has the tabs Work Alone Protection Sessions, Work Alone Protection Alarms and Work Alone Protection Call Attempts. On Android and iOS, workers manage their own sessions using Work alone protection.
Preparing the configuration and contacts is described in Setting up work alone protection. Worker actions are described in Work alone protection sessions in the mobile app.
Find a session and interpret its details
Select Work Alone Protection Sessions and enter the worker's name in the search field under the User Account Name column. Also check the Status column filter and the date filter above the table.
The default date filter is 6 months from today. The month options retrieve data from the selected number of months ago through today. Select Between dates... to specify your own start and end dates, or Anytime to remove this date restriction.
On each tab, the date filter applies to when the record was created: the session, alarm or call attempt. Both boundary dates are included in the search. It does not specify a range for check-ins, deadlines or end times. For example, a session started earlier that is still active today may be excluded by a date range that is too short. In that case, expand the date range and also check the individual column filters.
- Active means the session is running. It may have an active alarm or an alarm that has already ended.
- Stopped means the session has ended. The status does not indicate the worker's condition.
- Last Check-in At here means the most recent session check-in, not a login to the Spotilla app.
- Next Due At is the deadline for the next check-in. Checking in moves it forward from the check-in time by the session's check-in interval.
- Next Alarm Run At is a checkpoint for background alarm processing. It is not the same as the latest check-in or the actual time of a call.
- Interval (min) is the check-in interval taken from the configuration when the session starts. Later changes to the configuration do not change the interval of a running session.
The Session has alarm filter in the Alarms column also includes sessions whose alarms have already ended. It is based on the total number of alarms associated with the session, not just active alarms.
Open an alarm and its call attempts
Open the Alarms link on the session row to see the alarms associated with that specific session. On an alarm row, Call Attempts opens the calls for that alarm. Configuration details and Contact details open read-only details saved when the alarm was created. These windows cannot be used to edit the configuration or resolve the alarm manually.
The session's alarm window and the alarm's call attempts window show up to 500 of the most recent records. To review a longer history, use the corresponding tabs on the page and their filters.
For an alarm, check Status, Effective Section, Triggered Due At, Ended At and Email Sent At. Triggered Due At shows the time of the checkpoint that caused the alarm; it may differ from the alarm's actual start time.
For call attempts, check the contact's name, phone number, Contact Type, Position, Loop Index, Status and Provider Status. Position means the contact's sequence number within their contact section, not a geographical location. Loop Index indicates the round of calls within that section.
How does an alarm progress?
An alarm is created when a check-in for an active session is missed and the deadline check runs. A second alarm is not started for the same session while an alarm is already active.
Whether primary contacts are used is determined based on when the alarm is created. The check uses the configuration's weekdays, times and time zone. The start of the time window is included, but the end is not. Outside the time window, primary contacts are skipped if emergency contacts are available. If there are no emergency contacts, primary contacts remain in use.
Primary contacts are called in the configured order. The Retry calling times setting means the number of complete rounds, not additional retries after the first round. There is always at least one round. If the calls fail, emergency contacts are called next, for up to three rounds.
For example, two primary contacts and two rounds mean up to four primary call attempts in the order first–second–first–second. A successful attempt ends the alarm and stops further calls for that alarm.
Calls primarily use the contact snapshot saved for the alarm. However, not all processing values are frozen: the number of primary rounds and the recipients of backup emails are read from the current configuration during processing. The old snapshot in the Configuration details window therefore does not, on its own, show which values were actually used for these settings.
What do the statuses confirm?
- An alarm's Active status means the alarm process has not yet ended. The monitoring window has no action for manually marking an alarm as resolved.
- An alarm's Resolved by call status means the status returned by the call provider has been interpreted as a success. The provider's In progress status is also sufficient for this; the call does not need to have ended yet. This does not confirm that the worker is safe or stop the session.
- A call attempt's Pending status means the attempt is unfinished. The provider's Queued and Ringing statuses describe the call's progress. An attempt's Completed status means the call was interpreted as technically successful.
- No answer, Busy, Failed and Canceled do not mean the contact was reached. A technical error or a timeout when retrieving the call status can also cause an attempt to fail.
- An alarm's Failed calls (email sent) status means that, after the calls ended, backup emails were queued and an email timestamp was saved for the alarm. This does not confirm that the messages were delivered or read. If the current configuration has no backup email recipients, this final status is not reached and the alarm may remain active.
When an alarm ends, the session remains active. If the worker does not check in, a later check based on the check-in interval may create a new alarm. A late mobile check-in moves the next deadline forward, but does not by itself close an alarm that is already active.
Establish the worker's situation according to your organization's agreed procedure. A backup email sent after failed calls also requires the agreed follow-up. The monitoring log helps with subsequent investigation, but contacts must act according to the organization's agreed procedure.
Stop a session in the browser and verify the result
When a session should be ended, select Stop Work Alone Protection Session on its row. There is a circled cross next to the action. Check the user shown in the confirmation that opens, complete the required Stop Reason field and select Save.
A session can only be stopped if it is active and has no active alarm. While an alarm is active, the stop button may be visible, but the service prevents stopping the session. In the browser, an overdue check-in does not by itself prevent stopping. In the mobile app, the worker must first check in if the check-in deadline has been reached; an active alarm prevents stopping there as well.
Stopping saves the session status as Stopped, along with the stop time, the account that stopped it, the user type and the reason. It ends subsequent check-in deadline checks for this session. The session, its alarms and its call attempts are not deleted, and stopping does not record the worker's condition as verified.
Reload the monitoring page and find the same session. Verify Status, the stop time in the Stopped At column, Stop Reason, Stopped by user type and Stopped By Account Name. Also check the final times and statuses of the alarms and call attempts. An error message or a status that has not been refreshed does not confirm that the session was stopped successfully.