Beyond the Check Engine Light: Building IoT Alerts That Diagnose, Not Just Detect 

TL;DR

• Most industrial and commercial IoT alerts work like a car’s check engine light: one vague signal standing in for dozens of causes, making it easy for people to tune it out.
• The fix isn’t more sensors or more alerts. It’s better design: contextual thresholds, severity tiers, root-cause signals, and knowing the difference between quiet and broken.
• FourJaw’s shop-floor monitoring and Soracom’s connectivity and remote management layer show what trustworthy, actionable alerting looks like in practice.

---

Every driver knows the feeling. A small orange light appears on the dashboard.

The check engine light could mean a loose gas cap. It could mean a failing catalytic converter. It could mean nothing at all. There’s no way to tell from the light itself, and after enough false alarms, many drivers stop treating it as information and start treating it as noise – a potential problem should a real issue occur.

A lot of industrial and commercial IoT monitoring systems are built the same way. It’s not a data problem, it’s a design problem – and one with a clear solution.

---

When an alert stops being information

A system that alerts too often, on too little, ends up in the same place as a system that doesn’t alert at all: people stop listening. It’s the boy who cried wolf, retold on a factory floor. Sound the alarm enough times over nothing, and by the time something is actually wrong, no one comes running.

---

Why monitoring systems fail the same way

Most alerting failures trace back to a handful of the same design choices, regardless of industry.

• Static thresholds in a dynamic world. A single fixed limit, (i.e. alert if temperature exceeds X), may not account for normal variation across seasons, equipment age, or operating mode. Set it tight and it fires on harmless variation. Set it loose and it misses real problems.
• One alarm, many root causes. Like the check engine light, plenty of industrial alerts collapse dozens of distinct failure modes into a single undifferentiated signal. The person receiving it has no way to triage urgency without already knowing what’s wrong, which largely defeats the purpose of the alert in the first place.
• No severity tiering. Everything arrives on the same channel at the same priority, so a genuinely urgent event looks identical to a minor one until someone stops to investigate.
• Alerting on symptoms instead of causes. Flagging “temperature is high” is easier to build than flagging “the compressor is degrading,” but it places the burden of diagnostic work on the person monitoring the equipment, which is exactly the labor these systems are supposed to remove.
• The silent failure problem. This one gets less attention than it deserves. While no alert should ever be read as “everything is fine,” it can just as easily mean the device stopped reporting. A dead sensor and a healthy one produce an identical signal: silence. Unless a system is explicitly built to tell them apart, “no news” isn’t necessarily “good news.”

---

What trustworthy alerting actually looks like

The organizations that get this right aren’t running more sensors or sending more notifications. They’re applying a handful of design principles that turn volume into precision.

Thresholds should be contextual, not static, accounting for time of day, season, equipment age, or operating mode, so an alert reflects a genuine deviation instead of normal noise. Severity should be tiered, with a clear response attached to each level. Not every alert deserves a phone call: some are purely informational, some need attention before the shift ends, and some need attention right now. Naming those three levels explicitly lets people triage by glancing at a tag, instead of opening and reading every notification that comes in.

Where possible, alerts should point at a root cause rather than a raw signal. Combining vibration, temperature, and current draw, for instance, separates “something might be wrong” from “this specific thing is wrong.” These alerts should also start a workflow, not end one. An alert without a defined next step, a ticket, an escalation, a runbook, just adds to inbox volume.

The last principle is the one most systems skip entirely: explicit handling of silence. A trustworthy system distinguishes quiet-because-healthy from quiet-because-broken, which means device and connectivity health need to be monitored as their own signal, separate from whatever sensor data is riding on top of it.

There’s a real, if imperfect, benchmark for disciplined alerting. EEMUA 191, a long-standing industrial alarm management guideline, suggests something in the range of one alarm per ten minutes during steady-state operation, with nuisance alarms held under roughly 5 percent of total volume. It’s a standard built for process industries like chemical processing and oil and gas, so treat the exact numbers as directional rather than a target to copy into a different industry. But the underlying discipline, deciding in advance what deserves an operator’s attention, applies well beyond the plants it was written for.

---

Proof it works: FourJaw

Most manufacturers assume their equipment runs at roughly 50 percent utilization, but by FourJaw Manufacturing Analytics‘ account the real number is often closer to 20 percent. Because the people running the equipment can’t see it clearly, a monitoring system that adds noise instead of clarity only makes that harder to fix.

FourJaw’s early approach didn’t help. Reverse-engineering each machine’s control system meant custom integration for every brand and age of equipment, and relying on a customer’s Wi-Fi created a familiar problem: when a device went quiet, no one could say whether the machine had stopped or the network had. That’s the silent-failure problem playing out on a real shop floor.

FourJaw’s fix mirrors the design principles above. Instead of tracking dozens of noisy variables, it narrowed to one signal: power draw, read from a current clamp any technician can install in minutes. And instead of depending on a customer’s network, it moved to Soracom Air, so a quiet device reliably means a stopped machine, not a dropped Wi-Fi connection.

The result is monitoring people actually act on. One FourJaw customer, Lister Windows, produced 250 additional PVC windows a week after acting on productivity gaps the platform surfaced, the kind of outcome that only happens once a signal is trusted enough to change how a team runs its floor.

---

How Soracom supports trustworthy monitoring

Connectivity is usually treated as plumbing, invisible until it breaks. For a monitoring system specifically, reliable connectivity is essential for alert reliability, and that shows up in a few concrete ways.

Soracom Air provides device and session-level visibility as a distinct signal, so “is this device actually online” doesn’t have to be inferred from the absence of sensor data. That’s the silent-failure problem, solved directly: a system built on Soracom can tell healthy-and-quiet apart from broken-and-quiet, the exact ambiguity FourJaw ran into before it switched. A Virtual Private Gateway, paired with Canal, Door, or Direct depending on the environment, keeps telemetry off the public internet and on a consistent path, since packet loss or instability in transport is an underappreciated source of false signals in its own right.

Soracom Harvest handles collection without separate infrastructure to stand up, and Soracom Lagoon turns that data into dashboards and threshold-based alerting, the layer where the severity and context principles above should actually get configured, rather than left at whatever default a device vendor shipped with.

Turning those principles into rules is Soracom Event Handler’s job. It watches device metrics, connectivity state, SIM usage, and sensor payload values, and only routes a notification, to email, Slack, a webhook, or a cloud function, when something crosses a defined threshold: the mechanism that makes contextual thresholds and severity tiers real instead of aspirational, configured once at the platform level instead of hand-built by every team that needs one.

The piece most worth calling out is remote device management. Once an alert is validated as real, capabilities like Napter for remote access and over-the-air configuration let a team act on it, restarting a device, pushing a config change, adjusting a threshold, without a truck roll. An alert that ends in “someone drives out to look at it” is a much weaker product than one that ends in “the fix went out in the same five minutes the alert fired.” From there, Beam, Funnel, and Funk route validated alerts into the systems a team already works in, a ticketing system, Slack, a CMMS, instead of a dashboard someone has to remember to check.

---

Questions worth asking your own team

A few diagnostic questions are worth sitting with, regardless of industry.

• Do your people actually act on your alerts, or have they built a workaround, checking the dashboard only when something already looks wrong?
• Do you know your false positive rate the way you already know your uptime or your device count?
• If an alert stopped coming in tomorrow, would you notice, and would you know why?
• Can someone act on a real alert without leaving their desk, or does every alert still end in a truck roll?

None of these have a comfortable answer on the first pass, and that’s fine. The point isn’t to feel good about your monitoring system today, it’s knowing exactly where to start making it one people trust.

---

From noise to signal

The fix for a car was never more dashboard lights. It was better diagnostics that could say which system, and how urgent. The same fix applies to industrial and commercial IoT.

Most organizations still measure monitoring success by volume: sensors deployed, alerts sent, dashboards built. A more useful number is alert precision; of everything your system sent last month, how much led to a real action, and how much was noise your team has already learned to tune out?

This piece is part of a short series on what mature IoT monitoring looks like. Your Sensors Are Talking. Is Anyone Listening? covers the earlier problem, most connected devices generate far more data than anyone reviews or acts on. Beyond the Dashboard covers the later one, what happens once alerts are trustworthy and a system is ready to act on its own. Together, the three describe a path: from visibility, to trust, to autonomy.

---

If you’re ready to see where your own monitoring stands on that path, reach out to the Soracom team to talk through the connectivity and platform layer underneath it.