Spend and Performance Alerting With Named Owners

The alert that saves money is rarely the one about performance. It is the one about data that stopped arriving, which looks identical to a quiet day: spend flat, conversions zero, nobody suspicious until Thursday. Every system we build starts with a dead man's switch on each source, so when an extract has not landed inside its expected window somebody is told before a chart is read, and the affected pages are marked stale until it does. The five conditions worth interrupting someone for: A source that stopped landing. A schema that changed underneath the pipeline. Spend pacing against daily budget checked hourly, because a broken bid cap empties a budget in six hours and a daily report discovers it the following morning. A conversion event that stopped firing after a site deployment, which is the most common cause of the performance drops we are called about and almost never the first hypothesis on the table. And cost per acquisition drifting past a median absolute deviation threshold on residuals from a 28 day baseline, once day of week has been removed. Seasonality that defeats generic tools: Ramadan and the two bayram weeks move Turkish food and beverage baselines far enough that a model trained on last year fires for the same reason every year, and the religious calendar shifts roughly eleven days earlier each year, so a fixed date rule fails on a schedule you can predict. We encode the calendar as a regressor instead of raising thresholds until the noise stops, because a threshold raised to silence a known event is also raised for the unknown one. The alert budget: Each owner gets a fixed number of alerts per week, agreed before we build anything. When we exceed it we delete alerts rather than loosen thresholds. We review which alerts fired and produced no action after the first month and again after the third, and retire them. Every alert names an owner, links to the rows behind it and states the action expected. An alert with no action attached is a notification, and notifications are ignored by design. Routing, deliberately unequal: Slack digest for drift. Direct message to a named person for tracking breakage. Paging out of hours for exactly two conditions: spend runaway and pipeline death. Nothing else earns a phone call at three in the morning. Treating a cost per acquisition that will revert to its mean by Tuesday as an emergency is how a team learns to mute the channel, after which none of this works. What we do not sell: Anomaly detection as a product. Forecasting, which is a different engagement with different mathematics and a different way of being wrong. Alerts on metrics nobody owns, since the remedy for an unowned metric is an owner rather than a rule. We also decline to instrument an account whose tracking has known gaps we have not been allowed to fix first, because alerting on unreliable data teaches people to distrust every alert including the correct ones. How we start: The first week is spent reading incidents from your last two quarters, because the alerts worth building are usually reconstructions of failures you already survived expensively. What comes out of that week is a written list of conditions, owners and actions, which you approve before anything is wired. If that list is shorter than you expected, that is the result rather than a shortfall.