Skip to main content
Alerts is the screen the platform’s fraud alarm reports to. Once a minute it looks at the last 60 minutes of every organisation’s outbound calls, and when one is past its threshold, an alert opens here and an email goes out. The loss it exists for is the classic one on any phone system: stolen SIP credentials pumping premium calls from Friday night to Monday morning, discovered on the invoice. Everything needed to notice was already in the call records. This is the noticing.

​
The two measurements

Both are taken over the same sliding 60 minutes of outbound calls, per organisation. Volume is the more useful of the two early on. A destination with no rate is refused before it connects, so a fraudster still hunting for a route that works makes a great many calls and spends almost nothing — which the call count sees and the spend does not. An alert is critical when the figure is at least twice the threshold, and a warning otherwise.
One known blind spot, stated rather than hidden. A call record is written when the call hangs up, so a single three-hour call to a premium number is invisible until it ends. Fraud is normally many calls rather than one, so in practice the sweep fires early — but “in practice” is the honest phrasing.

​
The thresholds, and why they ship switched on

One set of thresholds applies to every organisation, edited at the bottom of this screen: Type an exact decimal for spend — it is kept as you typed it, never rounded through a number, because the figure is quoted back to whoever decides whether to cut a tenant off. 0 switches that check off. The next sweep uses whatever is saved, with no restart.
These are on by default, which deliberately breaks this platform’s usual rule that nothing happens until somebody asks for it. Retention destroys data, so a default there would be dangerous; an alert only says something, and a fraud alarm that ships switched off protects nobody on exactly the weekend it was built for. The defaults are generous on purpose — a legitimate call centre trips neither.
An organisation that legitimately runs hot can be given its own pair through the API, PUT /alert-thresholds/{organisation}: a value there overrides the default, and 0 disables that check for that tenant alone. Overrides are not drawn on this screen, because the default is the policy nearly every deployment runs on.

​
Who is told, and where

When an alert opens, three things happen at once:
  • It appears on this screen, for the operator and for that organisation’s own admins. The money is at least partly theirs.
  • Two emails go out, not one with everybody on it: one to the organisation’s admins and one to the operator’s, so neither side is handed the other’s addresses. See email.
  • A text message goes to the numbers in Text alerts to on the organisation, if any are set and the organisation has an SMS account. See SMS.
The daemon also logs it at warning level, which is the second witness: a customer’s money is actively walking out, and a log line about it at a level nobody watches is no diagnostic at all.

​
Acknowledging

Acknowledging means “I have seen this”, not “stop watching”. An alert is never deleted — the row is the record that the platform noticed, and it stays. Acknowledging closes it and records who did it and when; the first acknowledger is the one kept, so a second click cannot overwrite who actually saw it first. While an alert of one kind is open for an organisation, the sweep will not open another: that is what makes a check every minute livable. Acknowledge it while the overrun is still running and the next sweep opens a fresh one, one minute later. That is deliberate. Acknowledging must not be a way of not watching. Only an operator can acknowledge, and only an operator can edit the thresholds. They are the platform’s fraud policy, and an acknowledgement silences an alarm the operator may still be liable for. An organisation admin reads their own alerts and cannot close them.

​
Reading the screen

Filters for state (open or acknowledged), kind (spend or call volume) and severity. The default view is newest first. Nothing is firing is the good state. Each row carries the measured figure and the threshold it passed, inside the message, so the row answers “how far over” without opening anything.

​
What to do when one fires

First question, and it is usually the whole answer: is somebody there running a campaign? A broadcast or a dialler starting up looks exactly like this, because it is the same thing minus the theft. If nobody is, treat the credentials as compromised:
  1. Open the organisation’s call history, filtered to outbound, and read where the calls are going and which extension is placing them.
  2. Change that extension’s SIP password. The new one is shown once, and every handset on it must be given it again. See extensions.
  3. Block the address the registrations are coming from, on Bans.
An alert stops nothing by itself, and neither does setting the organisation to Suspended. That status is a label on the record; no part of the call path reads it. What actually stops calls is removing the way in — the credential, the address — or a prepaid balance running out. Do not treat a suspended tenant as a barred one.
A tenant that trips the alarm every week is not being watched, they are being nagged. Give them their own threshold rather than teaching everybody to click past the alarm.