Alarms & alerting

Monitoring is only useful if it reaches a human at the right moment — not too early (noise), not too late (an outage). WatchTower15 alarms are evaluated automatically after every check, open incidents with a severity, and deliver notifications through the channels your team already uses.

The rule catalogue

WatchTower15 ships a set of built-in rules covering the common failure modes. Each rule is one of two types:

Metric rules compare a numeric value (days-to-expiry, response time) against a threshold.
Boolean rules are pass/fail conditions (reachable or not, changed or not) and escalate based on how many times in a row they fail.

Rule	Type	Warning (default)	Critical (default)
SSL certificate expiring soon	metric	≤ 60 days	≤ 30 days
Domain (registration) expiring soon	metric	≤ 60 days	≤ 30 days
Service response slow	metric	≥ 10 000 ms	≥ 30 000 ms
Domain unreachable	boolean	1 consecutive	5 consecutive
Service unreachable	boolean	1 consecutive	5 consecutive
Service response failed	boolean	2 consecutive	6 consecutive
DNS changed	boolean	1 consecutive	— (warning only)
WHOIS changed	boolean	1 consecutive	— (warning only)

Severity & escalation

Severity is how WatchTower15 distinguishes “worth knowing” from “wake someone up”. It’s decided per evaluation:

Metric rules compare the scan value to the thresholds directly — over the critical threshold is critical, over the warning threshold is warning, otherwise clear.
Boolean rules escalate on a consecutive-failure streak. A rule opens at warning once it has failed its warning count in a row, and escalates to critical once it reaches the (higher) critical count. Where a rule’s warning and critical counts are equal — as with DNS changed and WHOIS changed — it stays warning-only; a single change is worth a heads-up, not a page.

This is why Domain unreachable pages you only after five consecutive failures by default, while a one-off blip merely raises a warning: sustained failure is what escalates.

Per-entity thresholds

Defaults are sensible, but every threshold and consecutive-failure count is overridable per resource. A payment endpoint might escalate to critical after two slow responses while a batch job tolerates ten; a flagship domain might warn 90 days before certificate expiry. Overrides are stored against the specific resource, so tuning one noisy service never changes the defaults for everything else.

Overridable	Applies to
Warning threshold	metric rules (days, ms)
Critical threshold	metric rules
Warning consecutive-failure count	boolean rules
Critical consecutive-failure count	boolean rules

Leave any override blank to fall back to the rule’s built-in default.

Incident lifecycle

Alarms are evaluated event-driven, immediately after each relevant scan is processed — not on a slow polling loop:

A scan completes for a resource. Transient outcomes (blocked, lookup_unavailable) are ignored — they never open or resolve an incident.
The matching active rules are evaluated.
If a condition is breached and no incident is open for that rule+resource, a new incident opens at the computed severity (warning or critical).
If the severity changes, the current incident resolves and a new one opens at the new level, so history reflects the escalation.
When the condition clears, the incident auto-resolves.

There is at most one open incident per rule per resource, so a persistent problem is a single actionable incident rather than a flood. A resource’s overall health reflects its highest open severity.

Notification channels

Incidents are delivered through alarm policies, which route to targets:

Targets — individual users, contact groups, or broadcast to all users / all groups in the organisation.
Channels — email (the default), plus Slack, Microsoft Teams, and generic webhook.

Every delivery attempt is recorded, so you can confirm an alert actually went out — and where.

Uptime, domain & service checks — the scans that feed alarms.
Security scanning — the certificate/DNS rules in a security frame.
Tagging — targeting policies at groups of resources.