# Alarm settings

> **You need:** *Alarm settings — view* to read, *Alarm settings — edit* to change. The dedicated role is `alarms_config_manager`; `admin` also has it.

Alarm settings decide when an alarm fires. They apply across the whole chain, not per store.

## The three families

| Type | Watches | Example of what it catches |
|---|---|---|
| **Order** | Individual orders | Orders sitting too long, or past their promised time |
| **Driver** | Drivers | A driver at the store too long without leaving — the pickup delay alert |
| **Branch** | Stores | A store under too much load, or with too many cancellations |

Each family holds several individual alarms. You can browse a family, open one alarm and change its thresholds or turn it off.

## Chain-wide, not per store

This is the thing to internalise before changing anything: a threshold applies to **every store**.

Tuning an alarm because one busy city-centre store is noisy also retunes it for the quiet suburban ones — where it may now never fire at all. You are always trading a false-positive problem at one store for a false-negative problem at another.

> If the real need is genuinely per store, a chain-wide threshold cannot express it. Set the threshold for the majority, and handle the outlier operationally rather than by moving the number until that one store goes quiet.

## Changing a threshold

1. Open the alarm family — order, driver or branch.
2. Open the specific alarm.
3. Change the threshold, or switch the alarm off.
4. Save.

Changes affect what fires from then on. They do not retroactively clear alarms already raised — clear those by archiving them, see [Branch alarms](/books/console-yF7/page/branch-alarms).

## Choosing a number

A good threshold fires **when someone should act** and stays quiet otherwise. Both failure modes are real:

| Too sensitive | Too lax |
|---|---|
| Fires constantly | Fires rarely or never |
| People stop reading alarms | Real problems pass unnoticed |
| Genuine problems buried in noise | Discovered from customer complaints instead |

The second is more dangerous; the first is more common — and it causes the second, because an alarm board nobody reads is functionally an alarm that never fires.

Before changing a number, look at what actually fired over the last week or two. Tuning from a specific bad shift produces a threshold shaped by an outlier.

## Turning an alarm off

Switching one off is legitimate when it does not apply to how you operate. It is not a fix for an alarm that fires too often — that is a threshold question, and turning it off removes the signal entirely rather than sharpening it.

Note what you turned off and why. An alarm silently disabled a year ago is indistinguishable from one that never fires.

## Related pages

- [Branch alarms](/books/console-yF7/page/branch-alarms) — acting on store alarms
- [Stores and driver alerts](/books/console-yF7/page/stores-and-driver-alerts) — acting on driver alerts
- [Archived alarms](/books/console-yF7/page/archived-alarms) — the history to tune against