We can't find the internet
Attempting to reconnect
Something went wrong!
Attempting to reconnect
Call-out alerting and escalation
AlertRoster was built for search and rescue teams. It knows who is on the roster tonight, wakes them, and keeps going down the list until someone answers — so a team mobilises while it still matters, not when somebody happens to check their phone in the morning.
The same roster and escalation runs critical infrastructure up/down alerting, for the on-call engineer who has to be woken when a site goes dark.
Call-out alerting from Cloud Bedrock. Not an emergency service or alarm equipment — read what that means .
Incident
DB-02 stopped checking in
Illustrative example. Timings come from the escalation policy you configure.
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.
Land, mountain, cave, swiftwater, and K9 teams. The reason AlertRoster exists, and the use case everything else was shaped around.
Retained and volunteer crews who need a turnout count before the appliance leaves the station.
Lifeboat crews, surf rescue, and swiftwater teams working to a tide and a daylight window.
Pre-dawn control work and in-bounds incidents, where the roster changes daily with conditions.
Flood, storm, and disaster relief volunteers who mobilise on short notice and stand down just as fast.
Rotas where a specific person has to be reached, not a general inbox somebody will read eventually.
Line crews and field techs called out to restore service, often to a site that has gone quiet.
Up/down and heartbeat alerting for the engineer responsible when production fails unattended at 02:00.
One roster, one escalation policy, and every channel that gets a person's attention.
Who is responsible, and when. Rotations, handoffs, and overrides live in one roster your team can read without asking anyone.
If nobody acknowledges, the alert moves to the next person on the policy. It keeps going until someone takes it.
Dead-man's-switch monitoring. When a system that should check in every minute goes quiet, that silence becomes the alert.
A native iOS app, desktop workstations, and on-premise audible and visual alerting hardware at the site itself.
Not alarm equipment — what that means .
Who was notified, on which channel, at what time, and who finally acknowledged — recorded per incident.
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.
Four steps, and the fourth one repeats until it doesn't have to.
From your monitoring, or from a heartbeat that stopped arriving.
The schedule says who is on call right now. No group chat, no guessing.
On every channel you have configured for them, at once.
An acknowledgement ends it. Silence moves it to the next person on the policy.
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.
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 and does not contact one on your behalf. 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.
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 push infrastructure, carrier networks, the public internet, and your own LAN and hardware.
Device settings — Do Not Disturb, Focus modes, silent mode, notification permissions, low power mode — can suppress or delay an alert. That is why the on-site channel exists.
The critical-alert capability on iOS, where available, requires an Apple entitlement and your explicit authorization. Where it is not available, alerts arrive as high-priority time-sensitive notifications, which do not bypass all device silencing.
We do not claim any alert is guaranteed to arrive, to arrive within a stated time, or to override a device's settings.
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.
Specifics, because "enterprise-grade" is not a specification.
AlertRoster is being rolled out with a small number of teams. If your operation has someone on call tonight, we would like to hear how it currently works.