John SerraTo get alerted when your business numbers change without drowning in noise, follow four rules. Alert only on events that force a decision. Set each line according to the kind of number it watches. Make every alert say what happened, who owns it, what to do, and by when. Then review the whole list regularly, and for any alert nobody acted on, find out why before you remove it.
Monitoring Is Not Alerting
Monitoring is a number you can look at when you choose to: a dashboard, a scorecard, a monthly report. Alerting is a number that interrupts you. They do different jobs, and most alert problems start when one is used as the other.
Anything that can wait until the next review belongs on the scorecard. How many KPIs a small business should track explains why four to seven numbers is enough to watch. An alert list should be much shorter than that. If you're not sure where a number belongs, put it on the scorecard first. You can promote it later.
Why Alert Systems Decay
An alert system usually starts with enthusiasm. You set up alerts for everything you'd hate to miss. Within a few weeks the messages arrive daily, people skim them, and somebody builds an inbox rule that files them away. When a real problem finally triggers one, it sits in a folder nobody opens.
Software makes sending a notification free. Attention is the part that costs something. The fix is not a better tool. It's a smaller list, with a clear reason for each item to be there.
Industrial plants have dealt with this for a long time. ISA's own explanation of alarm management, built around the ANSI/ISA-18.2 standard, describes rationalization: each alarm is justified, and its consequence, the expected response, and the response time are documented. ISA's overview of alarm rationalization is worth a read. A small business doesn't need that formality, and this article isn't claiming to follow the standard, but the discipline carries over.
What Deserves an Alert
Two tests keep the list short. First, does the number help the business make more revenue, run more efficiently, or cost less to operate? If not, leave it off. Second, if it moves, is there a decision someone must make soon, and can they make it? If the answer is "we'll look at it at the monthly review," it's a report.
| Alert | Report | |
|---|---|---|
| When action is needed | Before the consequence arrives, at a deadline set for that risk: minutes for an outage, about a day for a financial check | At the next scheduled review |
| What it watches | A limit you can't cross, or a sharp break from normal | Trends and gradual changes |
| Who receives it | One person who owns the response | Leadership and the team |
| How often it fires | Rarely, by exception | On a schedule |
Typical alert material: cash projected to fall below payroll, a product about to run out, a payment system that has stopped working, a key customer's orders stopping. Typical report material: utilization, retention, average ticket, anything you review monthly to see which way it's heading.
Two Kinds of Line
A threshold is the line a number crosses to trigger an alert. There are two ways to set one, and they suit different numbers.
A hard limit comes from what the business must be able to do, not from history. Cash is the clearest case. Your minimum cash level should come from what's due in the coming weeks and how quickly you could collect or borrow, not from last year's balances. Two $15,000 payrolls come to $30,000, but that covers only those two payments. A real floor also has to cover rent, vendors, taxes, and a margin for the forecast being wrong. The 13-week cash flow tracker shows one way to lay that out. Keep in mind that a check on week-end balances can miss a dip in the middle of a week. Inventory works the same way: set the reorder point from lead time and how fast you sell. A dangerously low balance can be common, so history isn't a safe guide here.
A variation band comes from how much a number normally moves. It suits performance numbers, such as inquiries, conversion rate, gross margin, or on-time delivery. I set these from the business's own history. I look at how much each metric actually moved over the last six to twelve months. Movement inside that normal range I treat as noise. Movement outside it means something changed. And I set the band metric by metric, because metrics differ.
The numbers below are made up to show why. Take two metrics from the same business.
| Weekly website inquiries | Gross margin | |
|---|---|---|
| Normal range over 12 months | 38 to 58 a week | 41% to 43% |
| Midpoint | 48 | 42% |
| A flat 10% rule fires when it falls below | 43.2 | 37.8% |
| Reading that should get attention | Well outside the range, such as 20 | 38% |
A 10% rule would alert on a perfectly normal week of 40 inquiries, which sits 17% under the midpoint but inside the usual range. It would stay silent when gross margin falls to 38%, because that is only 9.5% below 42%. Yet at $80,000 of monthly revenue each margin point is worth $800, so four points is $3,200 a month, or $38,400 a year if it lasted. Same rule, two wrong answers.
Two cautions apply. First, a steady drift that stays inside the band is still a trend, so keep watching it on the scorecard. Second, if you have no history yet, start with a rough band from your judgment and revise it after a quarter of real data. A first guess is fine as long as you replace it.
What a Good Alert Says
An alert that only states a number leaves the work to whoever reads it. Make every alert carry four things:
- The condition, in plain words.
- The context: how far off, and compared with what.
- The owner: one named person or role.
- The action and the deadline.
This is the same conversation a good reporting meeting has: what the numbers mean, who will act on them, and by when. Compare two versions of the same alert.
Weak: Cash is low.
Strong: Projected ending cash for the week of Nov 2 is $24,000, which is $6,000 under the $30,000 minimum. Owner: office manager. Next step: confirm which customer payments are due before Nov 2 and follow up on any overdue ones. Report back by Friday noon.
The strong version needs no meeting to decide who does what. The weak one starts a discussion about whether anyone should worry. The example is made up. In your own alerts, the owner should be a person or a role someone actually holds, not a shared inbox.
When Silence Is the Problem
A quiet inbox is weak evidence. It can mean everything is fine, but it can also mean the data stopped arriving, the monitor stopped running, or an alert is already active and is staying quiet on purpose. Keep three questions separate.
- Is the data fresh? Did the source refresh recently, with valid values? Use a timestamp for the last successful refresh, not the date of the latest transaction, which can be old for a good reason when nothing happened. A formula like
TODAY()or a header with a forecast date doesn't prove anything about freshness. - Is the monitor working? Did the check run recently, and did the message get out? A check inside the job that stopped can't announce that the job stopped. Use a separate backup check, such as a heartbeat message that should arrive and gets noticed when it doesn't. Set its cadence to the risk. Platform failure notifications help with runs that fail, but a missed-run check is needed for a job that never starts.
- Is the condition still active? A good alert system sends one message when a number crosses a line, then stays quiet while it remains crossed. No new message can therefore mean a problem that's already been reported, not a healthy number. Know which alerts are active and who has acknowledged them.
In a spreadsheet, a cell that records when the last successful refresh happened, with a rule that complains when it's too old, is a reasonable design idea. Treat it as a suggestion to try, not a tested recipe.
Plan for Known Noise
Some movement is expected and planned: a promotion that lifts inquiries for two weeks, a seasonal slowdown, a price change, a holiday closure. If an alert keeps firing for a reason everyone already knows, people start ignoring it for that reason and then for the next one.
Handle planned events deliberately, and be careful about which alerts you loosen. For performance numbers, write down the event, the dates, and the temporary band, and name the person who restores the original line. Don't switch off protections for cash, stock, outages, or safety just because the condition is expected. If you have to pause a critical alert, name another way someone will keep watching it and put the restore date on the calendar. A temporary exception with no end date quietly becomes a permanent blind spot.
Repeated alerts have remedies besides moving the line. For performance alerts where a short delay is safe, require the number to stay across the line for a few checks before it fires. Keep urgent hard-limit warnings prompt. Send one message per problem, not one per check. Let the owner acknowledge it, and escalate to a backup if nobody does. The Google SRE book's chapters on monitoring and practical alerting describe persistence, deduplication, and routing for engineering teams. The owner-and-backup response rule here is a proposed small-business routine.
Choose the Channel by Urgency
Match the channel to how fast the response has to be.
- Email suits checks you want a record of and can act on within the day, such as a morning cash check. It's easy to file and to find later.
- Team chat suits events a group handles together, such as a new qualified lead that someone needs to pick up.
- Text message or phone push suits emergencies where you'd want to be interrupted, such as a payment system going offline. If texts fire often, find out why. Either the lines are wrong, or a real problem keeps happening and needs fixing.
Decide what happens when no one responds. A simple rule is enough: if the owner hasn't acknowledged it by a stated time, the message goes to a named backup. This is also how you tell a missed alert from an unnecessary one.
Review the List Regularly
Alert lists need pruning, but pruning is not the same as deleting whatever gets ignored. A quarterly review is a reasonable routine for a small business, not a rule from any standard. Go through each alert and ask three questions.
- Did it fire? If not for a long time, is the condition still a real risk? A quiet alert may be doing its job, or it may be watching something that no longer matters.
- When it fired, did the owner act before the alert's own deadline? Compare the response with the deadline you set for that risk, not with a universal one. If they didn't act, find out why. The owner may not have seen it, the message may not have been delivered, nobody may have been named, there may be no backup, or the action may not have been possible. Fix that cause. Retire the alert only if the condition no longer needs a timely response, another alert already covers it, or it was only ever information.
- Did anyone say it was noisy? Find out what kind of noise it was before you change anything. It could be a real problem that keeps recurring, bad data, the same message sent twice, a number crossing the line and back again within minutes, a message that doesn't say what to do, or the wrong recipient. Move the line outward only when the number's own history supports it, and only for performance numbers. If the breach is real and repeats, that's an operational problem to solve, not a threshold to loosen.
Keep the list in one place with one row per alert, so the review takes minutes instead of an afternoon.
| Number | Line | Owner | Action | Channel |
|---|---|---|---|---|
| Projected cash | Below the cash floor (payroll plus other dated payments) | Office manager | Chase receivables | |
| Gross margin | Below its 12-month range | Operations lead | Review job costs | |
| Payment system | Offline | Owner | Switch to backup | Text |
The rows are examples. Yours should be short enough that the owner can name every alert from memory.
Frequently Asked Questions
How many alerts should a small business have?
As few as you can defend. A handful is plenty for most small businesses. If you can't say who acts on an alert and what they do, it doesn't belong on the list yet. Either name the owner and action, or move the number to the scorecard.
Should I alert on a percent change or on a level?
It depends on the number. Use a level, a hard limit, for cash, stock, and anything with a real floor. Use a variation band for performance numbers that move up and down on their own. A flat percentage for everything is the version most likely to be wrong.
What if I don't have 6 to 12 months of history?
Start with a rough band, mark it as provisional, and replace it once you have a quarter of data. Don't wait for perfect history before setting up the few alerts that guard a hard limit.
How do I set one up in a spreadsheet?
How to set up automatic alerts in Google Sheets covers the mechanics. This article is about deciding which alerts deserve to exist.