What a dashboard is for
A dashboard is a screen that turns a stream of sensor readings into something a person can understand quickly. Its job is not to show everything; it is to answer a few specific questions. Is anything wrong right now? Is something heading in a bad direction? What happened earlier? A dashboard that tries to answer every possible question usually answers none of them well.
Begin by deciding who will look at it and what decision they need to make. A facility manager checking whether rooms are comfortable needs something different from an engineer investigating why a pump keeps tripping.
Choosing how to show readings
Different views suit different questions.
- Current value: a single large number, such as the latest temperature, works for “what is it now?” Always show the unit and when the reading was taken.
- Line chart over time: the standard choice for trends, cycles and sudden changes. A reading that looks harmless alone may look worrying when you see it climbing steadily for hours.
- Status indicators: a simple normal, warning or fault marker is useful when there are many sensors and the viewer mainly wants to find exceptions.
- Map or floor plan: helpful when location matters, such as sensors spread across a site.
- Table: best for looking up exact values, and less so for spotting patterns.
A few habits keep charts honest and readable. Label axes and units. Use a consistent time range across related charts so they can be compared. Be careful with scales: a vertical axis that starts at an unusual place can make small changes look dramatic. Where readings are noisy, a smoothed line or an average can help, but showing how the smoothing was done avoids hiding genuine spikes.
Show when data is missing
One of the most valuable things a dashboard can do is show that data has stopped arriving. A flat line can mean a stable value or a dead sensor, and the two look alike unless the display makes the difference clear. Showing the time of the last reading, and visibly marking stale or missing values, prevents false reassurance. Gaps, spikes and similar issues in the readings themselves are covered under data quality.
What makes a good alert
An alert is a message sent when something needs attention. A good alert has four qualities: it is actionable (someone can do something about it), clear (it says which device, what was measured, and what the expected range was), timely (it arrives soon enough to matter), and rare enough to be trusted.
The simplest alert is a fixed threshold, such as notifying someone when a freezer temperature rises above a chosen limit. Thresholds are easy to understand, but they need thought:
- Duration: requiring the condition to last for a set period avoids alerts for a single brief blip. A door opening for a moment may briefly raise a temperature without being a real problem.
- Hysteresis: using one level to trigger an alert and a slightly different level to clear it prevents an alert from flapping on and off when a reading hovers near the limit.
- Rate of change: sometimes how fast a value moves matters more than where it currently sits.
- Absence: an alert for “no data received for a while” is often as important as any alert on the values.
More sophisticated approaches look for unusual behavior compared with a device’s own normal pattern, which is the territory of anomaly detection. These can find problems fixed thresholds miss, but they are harder to explain and tune, so many teams start with simple rules.
Alarm fatigue
When people receive too many alerts, they stop paying attention, and then miss the important one. This is called alarm fatigue, and it is one of the most common ways monitoring systems fail in practice. Some ways to reduce it:
- Separate severity levels. Urgent problems might trigger a phone call or message; minor ones can appear only on the dashboard or in a daily summary.
- Group related alerts. If a network outage affects fifty sensors, send one message about the outage, not fifty about the sensors.
- Add delays and repeat limits. Do not resend the same alert every minute. Remind occasionally, then escalate to someone else if nobody responds.
- Send alerts to the right people. Routing by area or responsibility keeps messages relevant.
- Review regularly. Keep track of which alerts led to action and which were ignored, then adjust or remove the noisy ones. An alert that nobody ever acts on is a candidate for deletion or redesign.
- Tune for the real situation. Limits that are sensible in summer may produce constant alerts in winter. Sensor accuracy and drift also affect what a reasonable limit is; see sensor calibration.
A worked illustration
Imagine a hypothetical cold storage room with a temperature sensor reporting every minute. A rule that alerts on any single reading above the limit might fire every time staff open the door. A better rule might alert only if the temperature stays above the limit for, say, ten minutes, and a separate rule might alert if no reading arrives for fifteen minutes. The first warns of a cooling problem; the second warns of a sensor or network problem. The right durations depend on the room and the goods, so they should be chosen by the people responsible, not copied from an example. Related monitoring needs are discussed in the article on the cold chain.
Keep it simple and test it
Start with a small number of dashboards and alerts that map directly to real decisions. Test alerts by deliberately triggering them, and confirm the message reaches a person who knows what to do. Remember that alerts depend on the system working: a notification will not arrive if the sensor, network or alerting service is down, so critical safety functions should not rely on a dashboard alone.