Email alerts when the call service, a provider, a desk phone, the disk or a backup needs attention.
You should not learn that the phones are down from a customer.
The alerts
| Alert | Waits before telling you |
|---|---|
| The call service is out of reach | 2 minutes |
| The call service restarted | Tells you at once |
| The database is out of reach | 2 minutes |
| A provider connection is down | 2 minutes |
| A desk phone dropped off | 10 minutes |
| The disk is nearly full | When under 10% free |
| A backup failed, or none has run | At once, or after the days you set |
Each can go to every administrator or to addresses you name, and every wait is adjustable.
Why they wait
One failed attempt that the next one fixes is not news. A desk phone that restarts to take new settings is back in a minute. The waits are what keep a blip from becoming a midnight email.
A restart is the exception. Even a quick one ends every call in progress, so you are told however short it was.
And when it is over
For the call service, the database, a provider and a phone, a second message says it is back and how long it was away. You should not have to check whether the thing you were worried about fixed itself.
Reading the message
Each alert says what, since when and why. A provider alert includes the reason the provider gave and whether Kahevo is still trying or needs someone to correct a setting. A disk alert says how much is left and which folders hold the most.
Phones that drop at the same moment arrive as one message, which is how a switch losing power reads as one event and not twenty.
What an alert cannot do
Be sent when the thing that sends it is down. If the server loses power or its network, nobody is told. If the office's mail server goes down with the internet connection, the alert has nowhere to go. The page says so, plainly. For those cases, an outside monitoring service that checks on the server is still worth having.