A gap is drawn as a gap
When a device is offline, the trend stops. It does not draw a straight line between the last value before the outage and the first one after it, because that line is a measurement nobody took.
Pulse reads your field continuously, shows it honestly, and calls the right person when something goes wrong. It sits on the tree you built in Atlas, so there is nothing to set up twice.
Zoom, pan, and put several pens on one axis without waiting for a page to rebuild. This matters more than it sounds: the difference between a chart that responds instantly and one that takes four seconds is the difference between exploring a problem and giving up on it.
A live chart running on real data will sit here. It is not here yet, because the honest version of this page does not fake the one thing it is claiming to be good at. Until then, the fastest way to judge it is a device on your own equipment.
Most monitoring software interpolates across an outage without telling you, so a backhaul failure looks like a steady reading. That is the single most misleading thing a trend can do, and it is a choice the software made rather than a limitation. These are commitments about what Pulse will not do.
When a device is offline, the trend stops. It does not draw a straight line between the last value before the outage and the first one after it, because that line is a measurement nobody took.
A value that arrived late, was clamped at the top of a sensor range, or came from a device reporting a fault is marked as such wherever it appears, including on a report you export.
Nothing is averaged or filtered by default. If you turn smoothing on the chart says so, because a smoothed trend that looks like raw data hides exactly the spikes you are watching for.
A correction is recorded alongside the original rather than replacing it, so the number you acted on in March is still the number you can see in June.
An alarm nobody sees is not an alarm. Rosters and escalation are platform features rather than monitoring features, so the chain you build here is the one every future module uses when it needs somebody at 3am.
Alarms are evaluated at the device as well as in the cloud, so a threshold is crossed and acted on even while the backhaul is down.
Writing a setpoint from a phone is genuinely useful and genuinely dangerous, so it is bounded at both ends. Every writable setpoint has a minimum and a maximum you configure, and a value outside that range is refused rather than warned about. A fat-fingered extra zero cannot leave the interface.
Writing is a named privilege separate from viewing and separate from acknowledging alarms, so somebody can be trusted to answer a callout at 3am without also being able to change how the equipment runs.
Every write is recorded with who made it, when, the previous value and the new one.
A demo unit on real equipment answers more in a week than any page can.