Pager fatigue in a ten-person company
Small businesses often copy enterprise monitoring patterns — dozens of alerts, no runbooks, and the same person fixing everything at ten pm. Slack turns red and nobody knows if something is down, noisy, or someone else's integration. Security basics matter, and so does ownership. An alert with no owner is just anxiety with a notification badge.
Before you add another integration or turn on proactive monitoring, name who responds, how fast, and what "fixed" looks like. Otherwise you train the team to ignore signals — including the ones that actually matter.
For each alert class, write five lines
Every alert should have a named owner — a human name, not "the team." A one-line description of the business impact: lost orders, wrong stock, compliance exposure, embarrassed customer. A first action to take: check queue X, restart service Y, call supplier Z. An escalation path if it is not resolved in N minutes. And a snooze policy — when it is acceptable to mute it, and for how long.
If nobody can name the owner, disable the alert until they can. Noise erodes trust faster than silence. Prefer fewer, louder signals tied to one report the room already uses — not fifty thresholds copied from a SaaS template.
On-call without heroics
A rotating primary and backup weekly beats one martyr who "just knows the systems." Document runbooks in the same place as the alert — not in a founder's head. This connects to the thinking in ownership that ships and handover when one person holds the truth.
Business hours versus out of hours should differ. Not every alert warrants a 2am page. Classify alerts into three buckets: wake someone, fix tomorrow, or informational. Founders especially default everything to urgent — that burns people and hides real fires.
Alerts that should exist for SMEs
Integration sync failed — with the last success time and affected records. Report refresh failed before the Tuesday huddle. Certificate or domain expiry. Backup job failed. Unusual login or permission change if you hold customer data.
Alerts that often should not exist yet: CPU thresholds nobody acts on, new-signup notifications to the whole company, duplicate copies of the same vendor email. Review quarterly — the same rhythm as a quarterly systems review without tool bloat.
Test alerts like you test backups
Fire a controlled failure quarterly: pause an integration, expire a cert in staging, run a restore drill. Confirm the owner responds, the runbook works, and escalation reaches a human. Untested alerts are wishful thinking.
Keep a simple alert register: name, owner, channel, threshold, last fired, last reviewed. Same visibility principle as clear ownership for system projects. When someone leaves, update the register before their inbox stops forwarding.
Vendor alerts vs your alerts
SaaS vendors flood admin inboxes with product news dressed as alerts. Route those to a digest or ignore them — do not train the team that every red badge means production is down. Separate vendor marketing from "your integration failed" in channels and in people's heads.
When an alert fires twice with no action, delete it or rewrite it. Stale rules are how teams learn to ignore the channel entirely. Review after every incident: was the alert useful, too noisy, or simply missing?
Book a review. Care when you want a partner for steady-state, not another tool sale. Areas we work — Teesside, North East, remote when fit.