Line-down alerts without false alarms
A line-down alert is only useful if it is true: someone woken at 2 a.m. by a false alarm soon stops looking. In Monitor by 2N5, a call that fails is retried before anyone is told, only four failures in a row open an incident, and the alert arrives by email, climbing layer by layer until someone confirms.
Summary
- A false alarm is an alert for a failure that did not exist, and it is the main reason a team stops trusting monitoring.
- The defense is the retest: a failed call is repeated, and an incident only opens after four failures in a row, the first and three retests.
- The alert arrives by email, with the evidence and a link; one tap on the link confirms that someone took over.
- If nobody confirms in the agreed time, the alert climbs to the next layer, and then to the company's administrators.
- The email carries the time, the SIP code and the Q.850 cause of each call, so the team can act without opening the system.
How do you get line-down alerts without false alarms?
With three defenses in sequence: redo the call that failed, require consecutive failures before opening the incident, and only then notify, by layers, until someone confirms. Each defense cuts one kind of false alarm, and together they make a notice on your phone at 2 a.m. mean the circuit really went down.
What is a false alarm in telephony?
A false alarm is a notice about a failure that did not exist, or that was already over when the notice arrived. In telephony, the most common causes are:
- a test call that failed once because of a hiccup on the route and worked on the next one;
- a problem on the monitoring side, which cannot test but blames the circuit;
- scheduled maintenance that nobody told the monitoring about;
- a threshold too tight for the network’s normal fluctuation.
The cost is trust. When many alerts are false, the team starts ignoring all of them, and the true one gets lost among them.
Why test again before alerting?
Because a single failure almost never says enough. Monitor by 2N5 calls each circuit, by default, every 15 minutes. When a call fails, it is repeated three times, 2 minutes apart. The incident opens with four failures in a row, the first and three retests; two good calls in a row confirm the recovery.
| Moment | What happens |
|---|---|
| The test call fails | Nobody is told; the test is repeated in 2 minutes |
| Second and third failures | Still nobody is told |
| Fourth failure in a row | The incident opens, with the evidence of each call: time, SIP code and Q.850 cause |
| A good call in between | The count starts over; the blip does not become an alert |
| Two good calls in a row | The circuit is back, and the incident closes |
The math of the wait: an outage that starts right after a good test is seen 15 minutes later at most, and the fourth failure arrives 6 minutes after that (2 + 2 + 2). In exchange for those minutes, the alert becomes reliable. When the failure is on 2N5’s side, the test is left without visibility, does not count against the circuit and never wakes your team.
How does the alert arrive?
By email, with the evidence, the codes and the incident’s numbers, and a link that confirms the person took over the incident, without logging in to the system.
Each person can have more than one email address within the layer; if one is not available, the message goes to the next, without waiting.
How does escalation work?
The alert climbs in layers until someone takes over. Layer 1 is told when the incident opens. If nobody confirms in the time set for the layer, layer 2 is told, then layer 3. A single confirmation, with one tap on the message’s link, stops the climb, and the incident shows who took over and when.
| Who | When they are told |
|---|---|
| Layer 1 | When the incident opens |
| Following layers | When the previous one does not confirm in the defined time |
| Company administrators | When no layer confirms |
| Customer contacts | When a service has a problem and when it is resolved; they are not part of the climb |
The time to the first confirmation feeds the SLA report as average response, which shows how long the team takes to take over. The glossary explains MTTR and MTTA.
How do you avoid alerts during maintenance?
With a maintenance window: the chosen circuits, at a set time, stop opening incidents. The window must exist before it starts; maintenance declared after the outage is just an outage. Anything beyond the agreed time counts again.
What else reduces false alarms?
- Measure the call, not the equipment. A registered trunk does not prove that the call connects; a false green is the other side of a false alarm.
- Compare the IVR with the reference recording, so that the carrier’s announcement does not pass as an answer.
- Have someone per layer, not just one person: a ladder with a single layer becomes a false silence when that person has no signal.
- Record maintenance beforehand.
For the full path, see alerts and escalation and how it works. When the incident opens, the guide Failing calls: diagnosis helps read the codes, and How to enforce a carrier SLA with proof shows what to do with the record.
Frequently asked questions
How do I get an alert when a phone line goes down?
Add the person's email as a contact in Monitor by 2N5. When an incident is confirmed, the message arrives with the evidence and a link, and one tap confirms that you took over.
What is a retest before alerting?
It is repeating the call that failed, after a short interval, before telling anyone. A one-minute blip, a route that failed once or a lost call do not become an alert. In Monitor by 2N5, the call is repeated three times, 2 minutes apart, and only four failures in a row open the incident.
How long passes between the outage and the alert?
At the default pace, an outage is seen on the next test call, within 15 minutes, and the three retests add 6 more minutes until the fourth failure. The notice goes out right after the incident opens. The interval between tests and the number of attempts exist to trade a few minutes for a reliable alert.
What if nobody answers the alert?
It climbs: if the first layer does not confirm in the defined time, the second is told, then the third. When no layer confirms, the company's administrators are told. A single confirmation, with one tap on the link, stops the climb and records who took over and when.
Can I silence alerts during maintenance?
Yes. A maintenance window covers the chosen circuits at a set time, and failures on those circuits during the window do not open an incident. The window must be recorded before it starts; anything beyond the agreed time counts as an outage again.