The alerting engine

The alerting engine turns the question your team asks a dashboard every morning into a rule the platform evaluates for you. You describe the measurable quantity once, as a metric, and then state the conditions under which somebody should be told.

It reads sources you already collect — time-indexed event tables, imported layers, operational data — so writing a rule never means re-implementing a query somewhere else. Metrics and rules are stored in the platform's own database, which is what makes them reusable across teams instead of trapped in one person's query tool.

Every rule starts from a saved metric, so the definition that drives a chart is the definition that fires an alert. Two steps, in this order: compose the metric, then state the condition.

• Metric: one measure, a time dimension and granularity, plus the dimensions and filters that scope it.
• Condition: a fixed threshold, a percentage change, or an absolute change against the previous period.
• Comparison period: day, week or month — whatever matches the rhythm of the thing being watched.
• Spatial constraint: an optional radius and the location dimension it applies to.
• Message: the text that arrives with the alert, carrying the location that triggered it.

Threshold rules cover the straightforward cases: a count, a rate or an index above or below a value you set. Change rules cover the cases where the number itself never looks large but the movement does — a price stepping up a tier, a tenfold rise in an area that is normally quiet.

Spatial constraints keep busy regions from drowning out the interesting ones. A rule can be limited to a radius around a place and evaluated against that same area, so what fires is local movement rather than regional volume.

• Density above a level within a fixed radius of a site or a city.
• A commodity price moving up a tier within a week.
• A weekly count exceeding its own moving average by a set percentage.
• A rate that stays above a level for several consecutive periods, not just once.

Each rule carries the notification actions chosen for it when it was written: notify in the app, or open a card on the response board the work belongs to. Severity, ownership and status are then tracked from that first card through to closure.

• An in-app notification to the people who own the metric.
• A card on a selected board, carrying the rule's message.
• A last-triggered record per rule, so a rule that has gone quiet is visible too.

Every rule keeps a last-triggered time — silence is information, not the absence of it.

Metrics and rules are stored with the platform's own data, not in a spreadsheet beside it. A rule written for one site can be copied to ten others, and a metric that one team trusts becomes the foundation the next team builds on.

Rules can be paused rather than deleted. When an operation changes — a site closes, a commodity leaves the list, a threshold turns out to be wrong — the rule is switched off and stays available with its message and its history intact.

Alerting fails in two directions: it stays silent about something that mattered, or it speaks so often that nobody reads it. The rule set is where both are managed, and the platform supplies the evidence to do it.

Reviewing the last-triggered times once a month is usually enough to see the shape of the problem. A rule that has never fired may be too loose; a rule that fires daily is either describing a real recurring condition or needs a longer comparison period.

• Widen the comparison period before raising a threshold.
• Add a spatial constraint when every region fires at once.
• Pause rather than delete, and revisit when the operation changes.
• Split a rule by region before assuming the metric itself is wrong.

Most teams begin with the number they already check by hand: the one somebody screenshots into a chat group each morning. That metric becomes the first rule, and the first month of triggers shows where the threshold and the comparison period really belong.

The rule set then grows the way the operation does — one queue, one site, one commodity at a time. Every rule is owned by the team that receives its alerts, so nobody is asked to maintain an alert they never see.