When green turns red, the phone rings.
StatusNest knows whether a website is online. AlertTray knows how loudly a person should be interrupted. The useful system appeared when the two were joined: detect one meaningful outage, route it by urgency, deliver it through independent channels, and leave enough history to explain exactly what happened.
Monitoring and notification look like one feature until either side grows up. Checking a domain is about schedules, timeouts, response codes, state transitions, uptime history, and incidents. Reaching a human is about severity, device tokens, phone numbers, email addresses, provider credentials, retries, and delivery receipts.
StatusNest owns the first problem. AlertTray owns the second. Their contract is one authenticated API request: what happened, how severe it is, and who should receive it.
StatusNest checks the domain on its five-minute schedule.
The projected status changes from online or unknown to offline.
A critical alert names the domain, failure, time, and intended owner.
AlertTray resolves push plus call and SMS, falling back to email.
Workers claim one task per channel and report each result.
StatusNest records what was sent, skipped, or failed in the event stream.
A site that remains down is not a new emergency every five minutes. StatusNest alerts only when status enters offline from online or unknown. Checks continue, but the same outage does not keep ringing the phone.
The important fact is not “the site is offline.” It is “the site just went offline.”
The sender chooses severity; one routing policy inside AlertTray chooses channels. That keeps integrations from growing their own inconsistent notification logic.
If a critical alert has no phone number, the missing call and SMS are reported and email becomes the fallback. A StatusNest request can override the AlertTray account’s contacts for that one notification, so the domain owner—not the integration owner—gets called.
- One task per channel. A notification expands into concrete delivery work with its own recipient, status, attempt count, result, and provider identifier.
- Claim before sending. Pending tasks move atomically to processing, preventing two workers from making the same call or sending the same text.
- Recover abandoned work. A task left processing by a crashed worker is returned to the queue after a timeout instead of disappearing forever.
- Record both sides. AlertTray keeps delivery outcomes; StatusNest appends an alert-sent or alert-failed event so its dashboard can explain the outage timeline.
StatusNest also publishes status pages for 100 popular websites. Those checks run in headed Chromium on a virtual display, because an HTTP response alone cannot tell the difference between a working page and a bot challenge.
The public monitors are deliberately separate from customer alerts: they feed uptime history and search-facing status pages, but never call anyone. The same product contains both systems without confusing their purposes.
The finished path crosses two web applications, two background processors, per-user event stores, a projected task queue, Apple Push Notification Service, SMTP, and a phone gateway that can read a critical alert aloud and confirm it was heard.
None of that complexity leaks into the monitoring rule. StatusNest still says one simple thing: this domain just went offline; reach this person urgently. AlertTray handles the rest.