Logging and alerting: knowing that something happened
Most compromises are found months late because nothing was watching. Seven signals worth alerting on, who receives them, and what to skip.
The short answer
Most compromised small business websites are discovered by someone else: a customer, a search engine warning, a blocklist, a bank. The average delay is months, because nothing was watching. Logging records what happened; alerting is what turns a line in that record into a message to a person while it still matters. Seven signals cover most of what a business website needs to know about, they must reach a named person by a channel they notice, and everything else should stay out of the way, because an inbox full of noise is how the real alert gets missed.
The seven signals
| Signal | What it usually means | Severity |
|---|---|---|
| Site down or a key page failing | Outage, expiry, bad deploy, provider incident | Critical: immediate, any hour |
| Error rate spike | A broken change, a failing integration, an attack in progress | High: within the hour |
| Failed logins in volume, or a login from an unusual place | Brute force, credential stuffing, or a compromised account | High |
| New admin user, changed permissions, new API key | Persistence being established, or an unauthorised change | High: immediate review |
| Deploy or file change nobody initiated | Compromise of the pipeline, platform or server | Critical |
| DNS or domain record change, registrar notice | Hijack attempt or an unplanned change with wide effect | Critical |
| Form delivery failure, or a sudden drop to zero submissions | Silent form breakage, costing leads daily | Medium: same day |
Making alerts land
- Name the recipient for each severity: a person, not a mailbox.
- Match the channel to the severity: phone or pager for critical, chat for high, digest for medium and low.
- Set thresholds from the site’s real behaviour, not defaults: what is a spike for this site.
- Test the path: trigger a test alert and confirm it reached the person, on their phone, at an inconvenient hour, once.
- Review monthly: which alerts fired, which were actionable, which thresholds to adjust.
- Write it down: what is monitored, who receives what, in the setup document.
What to skip
Individual bot requests, single transient errors, normal daily traffic variation, every successful deploy, every login. These belong in logs, available for investigation, not in alerts. The discipline is to alert on change that needs a decision and to log everything else. A setup that sends a notification for every event trains its recipient to ignore notifications.
What this means for you
You will not discover a problem by reading logs; you will discover it because an alert reached a person who acted. Set up the seven signals, route each to a named person by the right channel, test the path once, and keep the noise out. Then the months-late discovery by a customer becomes a same-hour message to your partner, which is the entire difference between an incident and a disaster.
Frequently asked questions
Our hosting dashboard shows logs. Is that not enough?
Logs you have to go and look at are enough for investigating after the fact. They do nothing to tell you that something is happening now. Alerting is the piece that turns a log line into a notification to a person, and it is the piece most small business setups lack.
Who should receive the alerts?
A named person who can act, by a channel that reaches them at the severity in question: a phone alert for the site down, a chat message for a form failure, a daily digest for low-severity items. Alerts sent to a shared mailbox or a former employee are alerts sent nowhere. Your partner, under an on-call arrangement, is the usual answer.
How many alerts should we expect in a normal month?
Few. A well-tuned setup on a healthy site produces a handful of actionable alerts a month, most of them handled before you hear about them. If the count is dozens a day, the thresholds are wrong and real alerts are being lost in the noise.