The Problems Nobody Alerted On
A firm without an IT department does not need more alerts. It needs a short, calm list of things worth fixing this week — the credential nobody retired, the server that stopped reporting, the disk heading for a wall.
In short
- Findings, not alerts. These are “worth fixing this week”, deliberately kept out of the urgent channel so they cannot cause fatigue.
- 45 standing checks across account hygiene, system health, exposure and behavioural drift.
- They clear themselves. Fix the underlying condition and the finding resolves without anyone closing a ticket.
- One finding per problem, not one per event. A credential retrying every twenty minutes is one item with a host list, not a thousand rows.
- A weekly digest at 9am Monday, written to be read over coffee rather than at 2am.
Most estate problems are not alerts
An account disabled two years ago that still tries to authenticate every twenty minutes from three machines. A domain controller that stopped reporting eleven days ago. Local administrator accounts that appeared on three workstations last month. A disk that will be full in six weeks.
None of these is an emergency. All of them are how an incident starts, and none will ever be noticed by a firm whose IT is a part-time arrangement — because nothing is alerting.
Route these through the urgent channel and you get alert fatigue, which reliably ends with the urgent channel being ignored too. These conditions are monitored; what they need is a different tempo.
Two channels, two tempos
The separation is enforced in the language too: findings are never called alerts, never called critical, and never phrased urgently. A calm channel that starts shouting stops being a calm channel.
A finding is a standing statement about the estate, not an event. When the condition clears, the finding closes automatically. There is no queue to groom and nothing goes stale because somebody forgot to tick it off — which is exactly what happens to a ticket list at a firm with no operations team.
What the 45 checks look for
A terminal server where the remote-desktop service and a single sign-on agent were both failing several times a day. Each time, everyone working on that server lost their session. Each time, the services restarted themselves within seconds and the server never went down — so uptime monitoring reported a healthy estate throughout, for weeks.
Chronolith reports it as one finding rather than as an alert per crash: which services, how often, on how many machines, how close together, and which one failed first. It also shows how many of each service’s failures had the other service anywhere near them — because on that estate one of them failed fifteen times and only four of those coincided, which meant the explanation everybody had been working from was the wrong way round.
| Category | Examples |
|---|---|
| Account hygiene | Disabled accounts still authenticating; a disabled account that succeeded; dormant accounts; passwords past their age; new local administrators; privileged group changes; service accounts logging on interactively |
| System health | Sources that went silent or stalled; forwarders offline, unable to read one channel, or reading fine and unable to deliver; audit policy switched off; security tooling in maintenance mode; clock drift; permission changes not being recorded; permission data that has aged out or was never collected; services that keep failing and restarting while the server itself never goes down; the product's own background components failing, or silently not running at all |
| Exposure | Remote desktop reachable externally; unauthorised remote-access tools; new unregistered hosts; new services; break-glass account use; no visibility of data leaving the estate; file-sharing protocols reaching the internet; devices on the network that report nothing about themselves |
| Drift | Logon volume shifts; first-time administrator behaviour; access boundaries being crossed; detections that have stopped firing; patch and backup gaps |
Dormancy, patch gaps and backup gaps all require a baseline — they are statements about something that used to happen and stopped. Those take thirty to sixty days of history before they mean anything, and the product says so rather than reporting a clean result from an empty baseline.
One finding per problem, not one per event
A retired service credential still held by a scheduled task can produce thousands of failed authentications before anybody notices. Alerting on each one is an alert-fatigue machine.
“Retries every 20 minutes from these three machines” is a fix path. A thousand rows is a scrollbar.
These ghosts survive for years precisely because nobody knows what still depends on the credential, so every attempt to clean it up breaks something. Naming the machines that still hold it is what makes the cleanup possible.
The same principle applies throughout: a finding names the affected set and what to do, rather than reproducing the evidence that produced it. The evidence stays searchable.
Why it will tell you to grow but rarely to shrink
Capacity advice is where monitoring tools most often embarrass themselves, and the reason is a confidence asymmetry that most of them ignore.
A finance server sits at four processors for fifty weeks of the year and is increased to twenty-four for the two weeks of year-end. Sample it in June and every statistic says shrink it. Act on that and the firm discovers the mistake at the worst possible moment.
So redlining — a present-tense fact — reports immediately with no history required. Headroom trends report with the window they were measured over stated alongside, so nobody mistakes thirty days for a year.
A Monday morning email, not a pager
- Grouped by category, so related work is done together rather than one item at a time.
- Formatted for action — what the condition is, which machines or accounts it affects, and what to do.
- Weekly by default, changeable to monthly or off without editing configuration files.
- Read at 9am Monday, not at 2am. The tone is deliberate and so is the schedule.
Not a security operations centre. A managing partner, an office manager, or an external consultant who visits monthly. The digest has to make sense to somebody who was not watching the console all week, and has to be short enough that they read all of it.
Common questions
Is this just a compliance checklist?
No. Every finding comes from telemetry the product already collects about your actual estate, not from a questionnaire. A checklist asks whether you have a policy; this reports that a specific disabled account is still authenticating from four named machines.
How do we stop it becoming another ignored queue?
Findings resolve themselves when the condition clears, so the list shrinks as work gets done rather than needing to be groomed. And the whole point of separating them from alerts is that this list is short enough to read — if it were not, it would be alerts again.
Can we dismiss findings we do not care about?
Findings can be acknowledged, and suppression exists with an expiry so a decision to ignore something is revisited rather than permanent. A silenced check that stays silenced for two years is indistinguishable from a check that was never written.
What if we have no baseline yet?
Several checks need thirty to sixty days before they can say anything, and they report that they are still establishing a baseline rather than reporting a clean estate. An empty result from an empty baseline is not a clean result, and the product does not present it as one.
Does this replace an IT provider?
No, and it is not meant to. It tells you what needs attention in language you can hand to whoever does the work — internal or external. For firms with an external provider, it is often most useful as the agenda for the monthly visit.