Lone worker safety, check-in and escalation

Lone worker check-ins that escalate until somebody answers.

Your staff arm a check-in before a home visit, a night shift or a drive out. Miss it, and AlertRoster alerts the supervisor on duty with the worker's last known position. If nobody acknowledges, it moves to the next person, and the next, until someone does. Every miss, who answered it and how long that took is kept in the incident record.

The same roster and escalation carries search and rescue call-outs and critical infrastructure alerting, for teams where an alert nobody hears is not an option.

Get started See how it works Book a call

Lone worker safety and call-out alerting from Cloud Bedrock. Not an emergency service or alarm equipment. read what that means .

Incident

Home visit check-in missed

Escalating

00:00 Renee Alvarez missed her 4:30 check-in. Alert raised to the Field staff roster, with her last known position.
00:00 Notified Dana Whitfield, supervisor on duty, by phone and workstation.
02:00 No acknowledgement. Escalated to the next rung.
02:00 Notified Marcus Ellery, on-call clinical manager.
03:12 Acknowledged by Marcus Ellery. Escalation stopped.

Illustrative example. Timings come from the escalation policy you configure.

For anyone who sends people out alone, and anyone who runs a call-out.

The pattern is always the same: a roster of people who have agreed to be reachable, an event that needs them now, and a window that closes.

Lone workers and their employers

Staff who go out alone on the job. The employer holds the roster: a missed check-in reaches the supervisor on duty, escalates until it is answered, and lands in the incident record.

Home health and in-home care

Aides, nurses and hospice staff visiting patients alone, in homes nobody at the agency has seen. A check-in for every visit, and a duress code for the one that goes wrong.

Janitorial and facilities

Night crews and building engineers working empty buildings after hours, often one to a site.

Security

Guards on solo patrol and mobile rounds, where the check-in is the patrol and a missed one needs somebody now, not at shift change.

Property management

Leasing agents showing units to strangers and maintenance techs alone in occupied homes and vacant ones.

Real estate agents

Showings, open houses and first meetings with a client, alone in a property somebody else chose.

Search and rescue

Land, mountain, cave, swiftwater, and K9 teams. What AlertRoster was first built for, and the hardest test the same escalation faces.

Volunteer fire and rescue

Retained and volunteer crews who need a turnout count before the appliance leaves the station.

Coastal and water rescue

Lifeboat crews, surf rescue, and swiftwater teams working to a tide and a daylight window.

Ski patrol and avalanche

Pre-dawn control work and in-bounds incidents, where the roster changes daily with conditions.

Community response teams

Flood, storm, and disaster relief volunteers who mobilise on short notice and stand down just as fast.

Utility and restoration crews

Line crews and field techs called out to restore service, often to a site that has gone quiet.

On-call clinical and veterinary

Rotas where a specific person has to be reached, not a general inbox somebody will read eventually.

IT and infrastructure on-call

Up/down and heartbeat alerting for the engineer responsible when production fails unattended at 02:00.

Households and people living alone

A daily check-in for someone living on their own, or "expect me back by six" for a solo hike. The missed check-in wakes the family or friends they chose.

Proven where it is hardest

AlertRoster was first built to call out search and rescue teams: volunteers woken in the middle of the night because someone is missing. The escalation that looks after your staff is the same one.

Critical Alerts, granted by Apple

Apple granted AlertRoster the Critical Alerts entitlement under its Public Safety app type, on the search and rescue use. That is a third party's judgement that these alerts are the kind that matter.

Built by someone who has run this before

Our founder was CTO of GEOS, where he architected, built and operated their 24/7 always-on life safety service as a hybrid cloud on AWS. Garmin acquired the assets of GEOS in 2021.

What it actually does

One roster, one escalation policy, and every channel that gets a person's attention.

On-call schedules and rotations

Who is responsible, and when. Rotations, handoffs, and overrides live in one roster your team can read without asking anyone.

Escalation policies

An ordered ladder. Each rung wakes its own people (named responders, or whoever a schedule says is on call) and waits its own time. Nobody answers, the next rung fires; the first acknowledgement stands the rest down.

Heartbeat and absence detection

Dead-man's-switch monitoring. When a system that should check in every minute goes quiet, that silence becomes the alert.

Personal check-ins

The same absence detection, for a person. Arm "expect me by six" or a daily check-in, satisfy it with one tap, and a missed check-in alerts your roster, escalating until someone acknowledges. A reminder before the deadline, with a one-tap extend, keeps a forgotten timer from waking anyone.

See how check-in works

Voicemail that pages

Route an after-hours line to a managed mailbox, and a message left there raises an incident to the on-call roster instead of waiting to be discovered in the morning.

Phone, desktop, and the room

Native iOS and Android apps, desktop workstations, and on-premise audible and visual alerting hardware at the site itself.

Not alarm equipment. what that means .

Acknowledgement you can go back and read

Who was notified, on which channel, at what time, and who finally acknowledged, recorded per incident.

APIs for your monitoring

Monitors, ticket systems, and on-premise agents raise and resolve alerts over documented APIs, each with its own revocable integration key.

Tenant isolation, enforced by the database

Separation between organizations is designed as a Postgres row-level security boundary rather than an application-layer convention. The policies land with the first domain migration.

How it works

Four steps, and the fourth one repeats until it doesn't have to.

1
An event arrives

A missed check-in, an SOS, an alert from your monitoring, or a heartbeat that stopped arriving.
2
The roster decides who

The schedule says who is on call right now. No group chat, no guessing.
3
They get notified

On every channel you have configured for them, at once.
4
It escalates, or it stops

An acknowledgement ends it, and stands down everybody else it woke. Silence moves it on to the next rung of the escalation policy, or to whoever the schedule names next.

Make the room aware, not just the phone

A phone in a pocket, on a loud floor, in a Focus mode, is a single point of failure for getting someone's attention. AlertRoster can drive on-premise audible and visual alerting hardware at the site, so an unacknowledged alert becomes something people in the space can hear and see.

We supply the software that commands that hardware. We do not manufacture, install, or maintain it.

What AlertRoster is not

AlertRoster is a call-out notification and escalation tool. It notifies people who have agreed in advance to be notified, and records what happened.

It is not an emergency service. It alerts the people on your roster, who decide whether to call one. Automatic SOS over satellite is coming soon. It is not a fire alarm, a security alarm, or an alarm monitoring service, and it holds no life-safety certification. It is not a replacement for your team's official paging arrangements, and it should not be the only way a call-out can reach your people.

What we will and won't say about delivery

Alerting products are usually sold on promises nobody can keep. Here is the honest version.

Alerts are delivered on a best-effort basis over networks we do not own: Apple's and Google's push infrastructure, carrier networks, the public internet, and your own LAN and hardware.

Emergency alerts sound through Do Not Disturb, Focus modes and silent mode on iPhone and Android, once the responder allows it in the app. On iOS that is Critical Alerts, which Apple has granted AlertRoster; on Android it is Do Not Disturb access for the emergency channel, which plays on the alarm stream.

Until a responder allows it, an emergency alert arrives as a time-sensitive notification, which Do Not Disturb, a Focus mode or silent mode can still hold back. High-priority alerts are time-sensitive by design. A phone that is off, out of signal, or has the app's notifications turned off receives nothing, which is why it escalates and why the on-site channel exists.

We do not claim any alert is guaranteed to arrive, or to arrive within a stated time.

There is no uptime or delivery SLA today. When there is one, it will be a contractual number rather than a sentence on a marketing page.

We hold no security or privacy certification at this time, and will name the specific audit when we do.

Under the hood

Specifics, because "enterprise-grade" is not a specification.

Elixir and Phoenix on the BEAM: A runtime built for large numbers of concurrent, isolated processes, which is what a fan-out of notifications is.
Every notification is a durable job: Notifications run through a Postgres-backed queue, so each attempt is recorded, retried on failure, and inspectable afterwards.
More than one node, clustered: The application can run across multiple clustered nodes that share queue state, so a node being replaced does not take the queue with it.
Health-checked rolling deploys: New versions roll out behind health checks, and traffic reaches the app over TLS.