Documentation

Appearance

Device Class Pulse ​

When a device class grows past a handful of units, the useful question stops being "does this one device look healthy?" and becomes "does this device still look like the rest of the product we ship?"

Pulse answers that question by learning an operational fingerprint from the class itself. Twice a day it samples enrolled devices, builds a peer model of what is normal for that product line, and points out outliers as the fleet evolves. You do not have to prescribe a gold state for every process, port, package, or binary up front.

Pulse workspace for a Northstar Edge Gateway class showing three devices drifting from normal, drift and coverage charts, and signal groups such as Identity, Processes, and Agent
Pulse watches the class as a population: what most devices look like, and which ones no longer match.

Why it matters ​

Connected products are mostly the same within a class. The OS image, agent, services, listening ports, and resource posture should cluster tightly. When a few devices diverge, that is often the first useful signal of a bad rollout, a customer-specific change, a missing service, or an unexpected process.

Prescriptive desired-state tools force you to declare that gold state in advance and keep it current. Pulse stays observational: it learns normal from peer devices, then explains the differences in plain language. That is a better fit for IoT fleets where "the same product" is the baseline, not a hand-maintained checklist.

Why Pulse waits for a larger class ​

Pulse works by comparing each device to its peers. That only becomes useful once a class has enough enrolled devices for "normal" to be a real pattern rather than noise from a few units.

When a class grows past 20 devices, fingerprints from the cohort start to be statistically meaningful. Shared OS identity, process sets, ports, and resource posture form a reliable baseline, and devices that diverge are more likely to point to interesting problems: a bad image, a missing service, an unexpected process, or a silent split after a rollout.

Until then, inventory, Device Check, monitors, and remote shell remain the right tools. Your organisation administrator can confirm whether Pulse is enabled for your team.

What Pulse collects ​

Pulse runs a platform-owned diagnostic through the same fleet fanout path used for other class probes. It runs as the unprivileged Dataplicity user on the device. No agent update is required.

Typical fingerprint fields include:

  • OS and kernel identity
  • uptime and load
  • available memory and root disk usage
  • mounts and network interfaces
  • common processes and listening TCP ports
  • selected package versions and allowlisted binary checksums
  • Dataplicity agent version

Missing tools or hardened /proc visibility on some devices are treated as coverage gaps, not as drift. Heterogeneous images are expected; Pulse continues with the fields each device can report.

How normal and outliers work ​

  1. Enable Pulse on the device class.
  2. Devices contribute fingerprints on a twice-daily cadence (UTC morning and evening slots).
  3. After enough successful fingerprints (about 20 participating devices), the class model warms up.
  4. Each device is scored against the peer model. Similarity below 85% surfaces as drift.
  5. Findings list the devices or cohorts that diverge, with the signals that contributed.

While the model is still learning, Pulse shows progress toward a baseline and holds back drift findings. Once warm, the overview shows how many devices are drifting, reporting coverage, and signal groups such as Identity, Processes, Network, and Agent.

Pulse findings list showing open elevated findings for devices whose process set differs from the common peer mass
Findings start from explainable differences, not an opaque score.

Read a finding ​

Open a finding to see:

  • which device or cohort is affected
  • the observed value versus what peers show
  • plain-language contributors such as a missing common process, an unexpected process, an unusual OS identity, or resource values outside the peer band
  • charts that place this device against the class distribution
Pulse finding detail for a device showing process-set evidence, peer share charts, and operator actions
Investigate the evidence, then decide whether the difference is a problem, an approved variation, or the new normal.

From a finding you can:

  • acknowledge it while you investigate
  • approve a known variation so similar differences stop looking like drift
  • mark a change as the new normal when the class has intentionally moved
  • dismiss noise that should not keep returning

Those labels feed the learning loop. Pulse stays useful as the product evolves without forcing a rewrite of a desired-state profile.

What Pulse is for ​

Use Pulse when you want to:

  • notice a small cohort that no longer matches the product line
  • catch silent image or service drift after a maintenance window
  • separate one bad unit from a class-wide change
  • give support a peer-relative starting point before opening a shell

Pulse stays observational. Pair it with monitors and alerts for paging, Alignment for short majority-response trackers, and desired-state profiles when you need explicit allowlists. Pulse does not auto-remediate devices.