Alarm timing and lifecycle

Networks are noisy. A port can bounce for a second, a ping can be missed once, CPU can spike briefly. Two timing settings, alarm delay and keep-alive, turn a technically-correct but noisy alarm into one your team actually trusts.

The difference in one line

Delay = wait before opening (“is this real?”). Keep-alive = wait before closing (“don’t disappear too fast”). They work well together: a 5-minute delay plus a 1-hour keep-alive gives you stable, trustworthy alarms.

Alarm delay

Alarm delay is a grace period before a newly-triggered alarm becomes active.

• When a rule first becomes true, the alarm enters a pending state instead of firing.
• If the condition is still true after the delay, the alarm becomes active and is shown and sent.
• If the condition clears before the delay is up, no alarm is ever raised: the blip is ignored.

Delay	Effect
No delay (0)	Fires on the first matching reading. Best for hard, unambiguous faults.
3 / 5 minutes	Ignores very short blips. A good default for links and reachability.
10 / 15 minutes	Only alerts on problems that persist. Good for utilization or temperature.
30 minutes	Only sustained, ongoing conditions raise an alarm.

When to use a delay

Use a delay for anything that can briefly fluctuate: packet loss, utilization, CPU. Use no delay for definitive events such as “device down” or “PSU failed” where you want to know immediately.

Keep-alive

Keep-alive is the mirror image of delay. Where delay stops an alarm from opening too quickly, keep-alive stops it from closing too quickly: once raised, the alarm stays open for at least the time you choose, even if the condition clears a moment later.

Why it’s useful:

• Prevents “flapping”: an alarm rapidly opening and closing as a value hovers around the threshold.
• Keeps an incident visible long enough for your team to see and act on it.
• Produces cleaner history and fewer duplicate notifications.

Keep-alive	Effect
Disabled	The alarm closes as soon as the condition clears.
30 min - 2 hours	Holds short-lived alarms open long enough to be noticed and triaged.
4 - 8 hours	Keeps an incident visible across a work shift.
16 - 24 hours	Ensures day-long visibility for significant events.

The life of an alarm

Understanding the states an alarm passes through helps you set delay and keep-alive with confidence.

State	What it means
Pending	The rule just became true, but the alarm is waiting out its delay. Not yet shown or sent. If the condition clears now, nothing is raised.
Active	The alarm is live: visible in the alarm list and delivered to your relays.
Cleared	The condition is no longer true (and any keep-alive time has elapsed). The alarm closes and moves to history.
Suppressed	You manually silenced this alarm for a chosen period, useful during planned maintenance.

A typical timeline with a 5-minute delay and a 1-hour keep-alive:

10:00  Rx power drops below threshold   ->  Pending (5-min delay)
10:05  Still below threshold            ->  Active: alarm raised, Slack notified
10:40  Rx power recovers                ->  held open by 1-hour keep-alive
11:05  Keep-alive elapsed, recovered    ->  Cleared: alarm closed, Slack notified

Tips and best practices

• Name alarms clearly and consistently: “<Device> <Metric> <Condition>”, like “OLT CPU High”.
• Match severity to real impact: reserve Critical for service-affecting faults so it stays meaningful.
• Add a delay to anything that fluctuates (loss, utilization, CPU); keep hard faults (device down, PSU failed) instant.
• Use keep-alive on flappy conditions: values that hover near a threshold benefit most.
• Put values in the message: include the reading and the threshold so notifications are self-explanatory.
• Compare to device thresholds where possible: for optics, compare Rx/Tx power to the vendor’s own warning levels instead of hard-coding numbers.
• Prefer sustained conditions: checking both the current and the previous reading (as the default loss alarms do) cuts false positives.
• Start from a default or duplicate: NetSense ships sensible default alarms; copy and adjust rather than starting from scratch.
• Test with a low threshold first: confirm the alarm fires and the message looks right, then set the real threshold.

Quick reference

Severity levels

Severity	Meaning
Critical	Service-affecting. Immediate action required (e.g. device down, PSU failed).
Major	Significant problem that will affect service if unaddressed (e.g. high memory, packet loss).
Minor	A problem worth attention but not yet impacting service.
Warning	Early notice / trending toward a threshold (e.g. temperature rising).
Cleared	Applied automatically when a condition resolves: the alarm closes.

Timing settings

Setting	Options	Purpose
Alarm delay	0, 3, 5, 10, 15, 30 minutes	Wait before opening: filters out brief blips
Keep-alive	Disabled, 30m, 1h, 2h, 4h, 8h, 16h, 24h	Minimum time open: prevents flapping

The report families

Device alarms	Port alarms
OLT	OLT Port
Switch	Switch Port
BNG	BNG Port
Server	Server Port
Generic device	-

Device alarms raise one alarm per device; port alarms are checked separately for every port. Choose the report type that matches what you want to watch, remember it can’t be changed later.