> ## Documentation Index
> Fetch the complete documentation index at: https://docs.firetone.com.au/llms.txt
> Use this file to discover all available pages before exploring further.

# Alerts

> The toll-fraud alarm: two measurements over a sliding hour, on by default, and what an operator does when one fires.

**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.

| Measurement        | What it catches                                                                  |
| ------------------ | -------------------------------------------------------------------------------- |
| **Outbound spend** | the money walking out, measured directly                                         |
| **Outbound calls** | pumping through unrated or flat-rate destinations, where spend alone stays quiet |

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.

<Note>
  **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.
</Note>

## The thresholds, and why they ship switched on

One set of thresholds applies to every organisation, edited at the bottom of
this screen:

|                    | Ships as             |
| ------------------ | -------------------- |
| **Outbound spend** | 50 per sliding hour  |
| **Outbound calls** | 200 per sliding hour |

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.

<Warning>
  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.
</Warning>

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](/operator/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](/tenant/phone-system/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](/tenant/phone-system/extensions).
3. Block the address the registrations are coming from, on
   [Bans](/operator/blocking).

<Warning>
  **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.
</Warning>

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.