Alerts and incidents - Netstamp Docs

Alert rules turn measurements into actionable incidents. A rule watches one check metric, evaluates it over a window, and opens an incident only after the condition remains true for the configured trigger duration.

Alert overview with open incidents, enabled rules, and notification readiness — Start in the incident list to see current attention, then move into a rule or incident for detail.

Supported metrics

Available metrics depend on the check type:

Check type	Common alert signals
Ping	Reachability, packet loss, and latency
TCP	Connection success and latency
HTTP	Availability, status validation, latency, body validation, and TLS certificate lifetime

Traceroute results are intended for investigation and do not currently provide alert-rule metrics.

Create an alert rule

Open Alerts in the project.
Choose Create rule.
Select a check and metric.
Choose an operator and threshold.
Set the evaluation window, minimum sample count, and trigger duration.
Choose a severity and notification destinations.
Save and enable the rule.

Alert rule editor showing check scope, metric, operator, threshold, and trigger duration — Define what is evaluated and how long it must remain true before an incident opens.

Alert rule editor showing severity and selected notification destinations — Keep routing explicit by selecting the destinations that should receive this rule's incident updates.

The evaluation window determines which recent samples are considered. The minimum sample count prevents decisions based on too little data. The trigger duration reduces noise by requiring the condition to stay true before Netstamp opens an incident.

Start with conservative thresholds based on observed baseline data, then tune them after reviewing real incidents.

Enabled alert rules with scopes, conditions, timing, and notification destinations — The rule list summarizes the complete evaluation and delivery policy for review.

Firing, clearing, and missing data

When an enabled rule has enough samples and its condition remains true for the trigger duration, it enters the firing state and creates or updates an incident.

When the condition no longer holds, Netstamp clears the firing state and resolves the incident. If there are not enough recent samples, the rule cannot make a reliable decision. Investigate assignment or probe connectivity instead of treating missing data as a healthy result.

Investigate an incident

Incident detail with affected probe, check, evaluation state, and timeline — Incident detail preserves the evidence and delivery timeline needed to investigate and review recovery.

When an incident opens:

Confirm the affected project, check, metric, and probes.
Inspect the corresponding Ping, TCP, or HTTP evidence.
Compare the start time with deployments or network changes.
Determine whether the problem is target-wide or isolated to specific probes.
Verify recovery after the rule clears.

The incident record remains available after resolution so it can support post-incident review.

Tune safely

Avoid changing several threshold settings during an active incident unless the rule itself is clearly wrong. After recovery, compare the incident against historical data, adjust one dimension at a time, and verify that the new rule still detects the failure you care about.

Use Notifications to configure and test the destinations attached to alert rules.