Write the alarm list
What genuinely warrants interrupting a person, who that person is, and what they are expected to do. If nobody would act on it, it belongs on a report — not in an alert.
Nobody watches a dashboard. The point is being told.
A screen on the wall is not monitoring. Monitoring is the right person finding out the one thing that matters, at the moment it matters, and hearing nothing at all the rest of the time. Getting that balance right is the entire job.
Alerts you will not mute
Context, not thresholds
A named owner per alarm
Tuned over the first month
THE SITUATION
Two ways monitoring fails, and both look like success at launch.
The first is silence. A dashboard goes up, everyone admires it for a fortnight, and then nobody opens it again. It was never anyone's job to look, and looking is not a job a person should have.
The second is noise. Alerts are switched on generously, because missing something feels worse than over-reporting. Within a month the phone has cried wolf sixty times, the group chat is muted, and the one alert that mattered arrives into a room that has already stopped listening. Both failures end in the same place: an expensive system nobody trusts.
SYMPTOMS WE HEAR MOST
A screen is up somewhere and nobody could tell you last week's readings Notifications for the system are muted on at least one phone When something failed, the data showed it — afterwards Nobody can say who is supposed to respond to a given alarmHOW THE WORK RUNS
Decide what deserves a phone call, then build backwards.
The order matters. Almost every disappointing monitoring project was built dashboard-first and alerting-last.
Build the context, not just the limits
Sustained duration, related sensors, schedules, and comparison against each asset's own history. This is what stops a defrost cycle looking like a failure.
Routing, escalation and acknowledgement
The right channel per severity, escalation when nobody acknowledges, quiet hours where they are safe, and a record of who responded and when.
Tune against reality
We review every alert that fired and every one that should have. Expect the thresholds you agreed on paper to change. That review is included, not an extra.
TUNE IT YOURSELF
One night. Set the sensitivity. Live with what you get.
A real shape of overnight data from three kinds of site. Drag the sensitivity and see exactly what would reach a person, what would be missed, and what that does to whoever is holding the phone.
ALERTS SENT
11
REAL PROBLEMS CAUGHT
4 of 4
MISSED ENTIRELY
0
FALSE ALARMS
7
20:00
READINGS TAKEN
0 / 1,440
YOUR PHONE
0 alerts
NOTHING YET
YOU WOULD BE MUTED BY FRIDAY
This is the more common failure. Every one of these reaches a person, most of them are nothing, and the human response is entirely predictable: turn it off. After that the system is worse than having none, because everyone believes they are covered.
QUIET, AND THAT IS THE PROBLEM
Barely any noise, which feels like success — and the failures that cost real money are exactly the ones that start small. A threshold high enough to be peaceful is a threshold that only tells you once it is already expensive.
CLOSER, AND STILL A COMPROMISE
You are trading a missed problem against a false alarm, because a single number cannot tell the difference between a defrost cycle and a failure. That is not a tuning error. It is the limit of thresholds.
GOOD RULES, SET TOO HIGH
Nothing false is getting through, which means the rules are doing their job. But the sensitivity is now above the subtle early warning — the rising current, the slow drift — and those are the ones that are cheap this week and expensive next month. Bring it down; the context rules will keep the noise out.
FLOODED AND BLIND AT THE SAME TIME
The worst of both. Enough false alarms that the alerts will be muted, and a threshold high enough that real problems are already slipping past. This is the state most generously-configured systems end up in, and it is why we do not sell thresholds.
THIS IS WHAT WE ACTUALLY BUILD
Same data, same night. The difference is that each alarm now carries context — sustained for how long, cross-checked against the door and the schedule, compared with its own trend rather than a fixed line. Everything real reaches somebody. Nothing else does.
21:14
Door opened for a stock check
Door sensor confirms a person, and it closed in 90 seconds
58
FALSE ALARM
22:02
Scheduled defrost cycle begins
Known cycle, on schedule, self-corrected
71
FALSE ALARM
22:40
Brief spike as warm stock loaded in
Recovered inside the expected window
44
FALSE ALARM
23:31
Compressor drawing more current than usual
Current trending up across three nights — this is the actual warning
38
ALERTED
00:12
Second defrost cycle
Scheduled and unremarkable
66
FALSE ALARM
01:05
Door opened, closed immediately
Under ten seconds
41
FALSE ALARM
02:48
Temperature above range and holding
Sustained 14 minutes, no door event, no defrost — this is a failure
82
ALERTED
03:20
Humidity drifting up
Consistent with the compressor issue, worth attaching to it
34
ALERTED
04:02
Network gap of four minutes
Device buffered and resent; nothing was lost
52
FALSE ALARM
05:11
Recovery after the overnight cycle
Normal morning behaviour
47
FALSE ALARM
06:30
Second unit failing to hold range
Independent of the first, sustained, and nobody is in yet
76
ALERTED
20:40
Cleaning crew triggers occupancy across three floors
Matches the cleaning roster exactly
61
FALSE ALARM
21:15
Lift called repeatedly
Same crew, moving between floors
39
FALSE ALARM
22:30
Water flow continuing after hours
No occupancy anywhere on that riser — this is a leak
45
ALERTED
23:50
Chiller cycling more often than usual
Efficiency dropping steadily over two weeks
36
ALERTED
00:30
Car park barrier activity
Registered tenant vehicle
33
FALSE ALARM
01:44
Fire door held open on level four
Compliance issue and a security exposure, still open 20 minutes later
79
ALERTED
02:20
Lighting circuit reports zero draw
Scheduled off, exactly as configured
55
FALSE ALARM
03:15
Temperature rising in a comms room
Cooling has stopped and the equipment in there matters
68
ALERTED
04:40
Sensor stops reporting
Battery low, not a building fault — schedule a swap
49
FALSE ALARM
05:30
Morning ramp-up begins
On schedule
43
FALSE ALARM
20:10
Shift changeover slows throughput
Happens every night at this time
51
FALSE ALARM
21:05
Vibration rises on conveyor motor
Trending up for eleven days — bearing wear, not noise
37
ALERTED
22:14
Line stopped for scheduled tool change
In the maintenance calendar
73
FALSE ALARM
23:02
Reject rate up briefly
First batch after the tool change, back to normal in six minutes
42
FALSE ALARM
00:20
Air pressure below spec and staying there
Sustained, affects three machines, quality will drift
80
ALERTED
01:30
Operator pauses the line
Logged, with a reason
46
FALSE ALARM
02:55
Oven temperature oscillating wider than usual
Control loop degrading — cheap now, expensive later
35
ALERTED
04:10
Consumable running low
Real, but it is a reorder, not a 4am phone call
57
FALSE ALARM
05:20
Second motor shows the same vibration signature
Same batch of bearings — worth knowing before both fail
64
ALERTED
Context rules are the service. A threshold is a setting; knowing that a rising current across three nights matters more than a door opening is the engineering.
We do not hand this over on day one and call it done. The first month is spent tuning against your real data, because nobody gets these numbers right from a specification.
SO WHY BUILD A DASHBOARD AT ALL
Three jobs a screen does well. Watching is not one of them.
If alerting is what protects you, the dashboard earns its place differently — and knowing which job you need changes what we build.
Answering a question
Somebody asks whether the cold room held range all weekend, or which unit is costing the most to run. A good dashboard answers in ten seconds instead of an afternoon of exports.
ON DEMANDProving what happened
An audit, an insurance claim, a customer dispute, a compliance requirement. The value is a defensible record with timestamps, not a live gauge.
AFTER THE FACTFinding the pattern
Alerts tell you about today. Trends tell you a motor has been getting worse for eleven days, or that one site consistently uses more than an identical one. This is where the money actually is.
OVER TIMEDesign for whichever of these you will really use. A screen built to be stared at gets ignored; a screen built to answer questions gets opened.
WHAT WE BUILD ON
Your data, in tools you can keep.
Nothing here is proprietary to us. If you part ways with us, the monitoring keeps running.
TIME-SERIES STORE
Keeping readings efficiently at volume
InfluxDB, TimescaleDB, Prometheus
DASHBOARDS
Views for questions, proof and trends
Grafana, or custom views inside your own platform
ALERTING
Deciding what reaches whom, and when
Rules in your Laravel platform, Grafana alerting, Alertmanager
DELIVERY
Reaching a person who is not at a screen
WhatsApp, SMS, email, voice call, Slack or Teams
DEVICE HEALTH
Knowing a sensor stopped reporting
Heartbeat monitoring, battery and signal tracking
RETENTION
How long readings are kept and at what resolution
Downsampling policies agreed with you up front
A silent sensor is the most dangerous state in monitoring. Device health is not an optional extra.
WHAT YOU ACTUALLY GET
Alerting people trust, and views they actually open.
- Written alarm list with a named owner per alarm
- Context rules — duration, related sensors, schedules, per-asset baselines
- Severity routing across WhatsApp, SMS, email and voice
- Escalation when an alert is not acknowledged
- Acknowledgement and response logging
- Dashboards built for questions, proof and trends
- Trend and comparison views across sites or assets
- Device health and heartbeat monitoring
- Data retention and downsampling policy
- One month of tuning against your real data, included
HONEST SCOPE
Is this the right thing to buy?
GOOD FIT WHEN
Something already reports data and nobody is acting on it A failure overnight or at a weekend would cost real money There is a person who can respond when an alert arrivesWAIT, OR DO SOMETHING ELSE FIRST
Nobody would change what they do regardless of the reading There is no one to respond out of hours — fix that first, or alerts are theatre Nothing is instrumented yet; start with device connectivityCOMMON QUESTIONS
The things people ask first.
How is this different from your IoT connectivity service?
Connectivity gets the signal in and makes something happen — a door opens, an order is raised. This is what you do with the stream once it exists: continuous state, exception detection, and deciding what deserves a person's attention. Many projects need both, and connectivity comes first.
We already have a dashboard nobody looks at. Can you fix it?
Usually, and the fix is rarely the dashboard. It is defining what should have interrupted someone and building the alerting that does it. Once people trust the alerts, they start opening the dashboard voluntarily — to answer questions rather than to keep watch.
How do you stop alert fatigue?
Context instead of thresholds, severity routing so not everything is urgent, escalation instead of broadcasting to a group, and a monthly review of every alert that fired. If an alarm has no owner and no action, we remove it.
Where do alerts actually go?
Wherever the person will see them. In Singapore that is usually WhatsApp for most severities, with SMS or a voice call reserved for the genuine wake-up cases. Email and Slack or Teams for anything that can wait until morning.
What if a sensor simply stops reporting?
That is treated as an alarm in its own right, because silence looks identical to everything being fine. Heartbeat monitoring, battery and signal tracking are part of the build, not an upgrade.
How long do you keep the data?
As long as you need, at a resolution we agree. Full resolution recently, downsampled further back — that keeps storage sensible while preserving the trends that make long-term comparison possible.
Tell us what you would want to be woken up for.
That one answer is usually enough for us to tell you what to instrument, what to alert on, and what belongs on a monthly report instead.