nRF Cloud Express

Feedback
Feedback

If you are having issues with the exercises, please create a ticket on DevZone: devzone.nordicsemi.com
Drag & Drop Files, Choose Files to Upload You can upload up to 2 files.
Register

Device Vitals and device search

Device Vitals

Device Vitals turn the core metrics described in Inspecting metric payloads into four pre-built, fleet-level insights. You don’t have to build these charts yourself; once the relevant metrics are being collected, the insight is available to drop onto a dashboard.

  • Battery Life: projects expected hours of battery life from the average rate of state-of-charge drop per hour, letting you compare battery life across software versions (a regression here often means a new build is burning power somewhere it shouldn’t).
  • Stable Hours: the percentage of operational hours a fleet accumulates without a crash. On MCU, a “crash” here means an unexpected reboot; on Android and Linux, it means a captured trace. This is the headline reliability number most teams watch across a release.
  • Connectivity: the success rate of data syncs (for devices that sync periodically) or uptime percentage (for always-connected devices), depending on which connectivity metrics your device reports.
  • Flash Wear: an estimated flash lifetime in years, computed from bytes written/erased against your flash hardware’s rated program-erase cycles. This is useful for catching a firmware change that suddenly writes to flash far more aggressively than before.
Device Vitals in Device Overview Page

Each of these is comparable across software versions and cohorts, which is usually a more actionable view than a single fleet-wide number: “is 1.1.0 worse than 1.0.0” tends to be the question you actually want answered.

Device search

Device Vitals and issue charts tell you that something is wrong in aggregate. Device search is how you go from that aggregate signal to the actual list of affected devices. It supports combining multiple filters (combined with AND; multiple values within one filter are OR’d together): device serial (with wildcard matching), current cohort, hardware version, current software version, and more. That way you can express something like “beta cohort, hardware version tracker-pvt, software version starting with 1.1.”

Saved searches let you keep a filtered view around instead of rebuilding it every time you check in on a particular slice of the fleet.

(Optional) Practice: correlate low device sync success with crashes

Try this in the nRF Cloud sandbox to put the timeline and Connectivity vital together:

  1. Use device search to find a specific device with a low connectivity sync success.
  2. Open that device’s timeline and look at whether failed syncs (sync_failure) cluster around the same time as reboots or crashes on that device.
  3. If they do, open the corresponding issue and check whether its trace detail (backtrace, logs) suggests a plausible reason the sync would fail.

More on this

This is a good habit to build early: a fleet-level metric regression is rarely the full story on its own, and the device timeline is usually the fastest way to find out whether two things that look correlated in a dashboard are actually causally related on a real device.

Make sure to Log in or Register to save your progress

Back
Next

Switch language?

Progress is tracked separately for each language. Switching will continue from your progress in that language or start fresh if you haven't begun.

Your current progress is saved, and you can switch back anytime.

Register an account
Already have an account? Log in
(All fields are required unless specified optional)

  • 8 or more characters
  • Upper and lower case letters
  • At least one number or special character

DevAcademy
Forgot your password?
Enter the email associated with your account, and we will send you a link to reset your password.