2GT-RichandClaude Opus 5
e10f7ba568
Documentation only — no functional change.
The README was carrying two jobs for two different readers. Its Reference section was
the single largest block at 154 lines, and nobody deciding whether to try the project
reads an InfluxDB environment variable table — while the people who need it were
scrolling past the pitch to reach it.
Split along that seam: anything you would read before installing stays in the README,
anything you would read after installing moves to docs/.
README.md 430 lines sell, prove, install, feature overview
docs/change-guard.md 193 safety system, settings, guard states
docs/architecture.md 116 data stores, polling model, module layout
docs/capsman.md 84 role model, radio matching, current limits
docs/alerting.md 81 rules, channels, webhooks, maintenance windows
docs/api.md 77 scoped tokens, preflight, scripting
docs/configuration.md 76 environment, secrets, rotation, TLS
docs/sso-oidc.md 71 identity provider setup and behaviour
docs/README.md 20 index
In-repo rather than a documentation site, deliberately. A change to Change Guard's
semantics can edit its documentation in the same commit as the code — which, given how
often that behaviour has been refined recently, is the property that actually matters.
A static site generator can point at docs/ later without moving a file.
The Change Guard pitch stays on the front page: the problem framing, the verified
recovery timeline and the quoted prediction warning are what make someone care, and a
reference page is the wrong home for them.
Three sections are new rather than relocated, written because the split exposed the gaps:
- architecture.md did not exist. It now records why there are three data stores, the
polling cadences, and which modules are pure functions over a snapshot and why.
- Scoped API tokens shipped without usage documentation. api.md shows preflighting a
change from a script and reading the guard block afterwards.
- change-guard.md records why ip-on-bridge-port is informational rather than critical
on RouterOS 7 — reasoning that previously existed only in a commit message.
Every internal anchor and cross-file link verified to resolve, including anchors into
other documents. No content dropped, checked by keyword comparison against the previous
single file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.3 KiB
Alerting
Alert rules
Each rule can be enabled independently, with its own threshold where applicable and a cooldown that prevents a flapping device from flooding your channels.
| Event | Notes |
|---|---|
device_offline / device_online |
Raised by the poller; recovery closes the outage record |
high_cpu / high_memory |
Configurable threshold |
cert_expiry |
Certificate approaching expiry |
firmware_update_available |
A newer RouterOS release exists for the device |
log_error / log_warning |
Matched from the device's own log |
device_discovered |
An unmanaged neighbour appeared via LLDP/CDP/MNDP |
config_drift |
The device's configuration changed (off by default) |
Alerts are suppressed for devices inside an active maintenance window.
Delivery channels
Email, Slack, Discord, Telegram and ntfy. Channels are configured under Settings → Alerts → Channels; secrets are masked on read and preserved when you save a channel without retyping them.
ntfy
Works with the public ntfy.sh or your own instance.
| Field | Notes |
|---|---|
| Server URL | Blank for https://ntfy.sh, or your own instance |
| Topic | Required |
| Access token | tk_…; preferred, since it can be scoped and revoked |
| Username / password | Basic-auth alternative |
| Manager URL | Optional — makes each notification tappable, opening the device it refers to |
Authentication is optional, but an unprotected topic means anyone who guesses the name can publish to it, so use one of the two.
Priority mapping. Severity maps onto ntfy's 1–5 scale so the channel stays worth being woken by:
| Events | Priority |
|---|---|
| Device offline, log errors, CPU/memory pressure | 4 — breaks through do-not-disturb |
| Certificate expiry, config drift, firmware available | 3 — default |
| Device recovery, new device discovered | 2 — low |
Each notification carries its event type as a tag, so a client can be filtered to wake only for the events you care about rather than needing a channel per event.
Outbound webhooks
Subscribe any URL to twelve events: device up/down, log errors, high CPU, high memory, certificate expiry, device discovered, firmware update available, config drift, and firmware rollout completed/failed.
Deliveries are JSON POSTs, HMAC-SHA256 signed in X-MTM-Signature when a secret is
set. Last-delivery status is tracked per webhook and there is a Send-test button.
Webhooks fire through the same pipeline as other alerts, so they respect alert rules, cooldowns and maintenance windows rather than bypassing them.
Scheduled email reports
Daily, weekly or monthly HTML fleet summaries to any recipient list, using the same SMTP settings as email alerts. Each report covers devices online, outages and total downtime, error and warning counts, updates pending, backups taken, and top clients by traffic. Send-now is available for an immediate copy.
Maintenance windows
Schedule planned downtime per device, or across a group, so alerts are suppressed automatically rather than being muted globally and forgotten.
- One-time or recurring (cron-based)
- Active windows can be deactivated early
- Managed under Settings → Maintenance