Alerts & maintenance
An alert nobody sees is a dashboard. An alert that fires constantly is noise people learn to ignore — which is worse, because it teaches them to ignore the real one.
Channels
Add as many as you need under Notifications.
| Field | Type | Notes |
|---|---|---|
| Telegram | channel | Fastest to set up. A bot token and a chat id. |
| Slack | channel | An incoming webhook URL. |
| channel | Your own SMTP server — the credentials stay encrypted at rest. | |
| Webhook | channel | A POST to your endpoint. For PagerDuty, Opsgenie, or your own tooling. |
| Browser push | channel | Notifications on your computer or phone, even with the app closed. Turn them on per device under Notifications → Alerts on this device; on iPhone and iPad, add the app to your Home Screen first. |
Send a test message when you add a channel. Finding out it was misconfigured during your first real outage is a bad way to find out.
How fast should it fire?
Set alert_sensitivity per monitor. The trade is always the same: fire early and you catch outages fast but page people for blips; fire late and every alert is real but you hear about it later.
| Field | Type | Notes |
|---|---|---|
| immediate | string | Alert on the first failed check. For things where seconds matter and a false alarm is cheap. |
| balanced | string | Sustained failure. The default, and right for almost everything. |
| relaxed | string | Only prolonged outages (~5 min). For endpoints that are known to be flaky and not worth waking anyone for. |
Slow, but not down
response_time_warning_ms alerts on a response that succeeded but took too long. This is usually the one that catches a problem before customers do — degradation almost always precedes failure.
AI diagnosis
On paid plans, a failing monitor has a Diagnose with AI button.SysOps probes the target — DNS, the port, the TLS certificate, the response — and a model reads the results back in plain English: what broke, and what to do.
The measurements are shown alongside the explanation, deliberately. The model is interpreting evidence and can be wrong; the evidence cannot. Its confidence is stated so an uncertain answer does not read like a certain one.
Maintenance windows
Planned work should not page anyone. Schedule a window and alerts are suppressed for its duration — but probing continues, so you keep the history of what actually happened while you were working.
curl -X POST https://sysops247.io/api/v1/maintenance-windows \
-H "Authorization: Bearer $BEACON_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"title": "Database upgrade",
"starts_at": "2026-02-01T22:00:00Z",
"ends_at": "2026-02-01T23:30:00Z"
}'Prefer this to pausing a monitor. A paused monitor records nothing, so afterwards you cannot tell whether the work caused an outage — which is the one question you will want answered.
A monitor under maintenance shows the state on your status page too, so customers see planned work as planned rather than as a failure.