Device Health

Admin › Assets › Device Health runs a set of health checks over every device your device management tools (Google Devices, Jamf Pro, Microsoft Intune, Mosyle) already sync into schoolAssets. Each check reads what the MDM reported about a device and the device's own record and decides whether the device is Passing or has reached one of the check's levels: Info, Warning or Failing. Each level starts at its own number (365, 180 and 90 days before support ends, say) and does its own thing when a device reaches it: nothing but record it, one notification to a team, or a ticket on the device that closes itself when the device recovers. That's how an early heads-up reaches the people planning a refresh months before a technician gets a ticket.

Checks run on each device right after its MDM sync. The date-based ones (support ending, warranty expiring, not checking in) also run once a day, since their answer moves with the calendar. A device with no synced MDM record has no checks.

The checks#

Every check starts turned on with the levels below and records its result only. Each one applies to the devices whose MDM reports what it reads.

| Check | Reads | Devices from | Starts with | | --- | --- | --- | --- | | Support ending | The device's Support End Date | Google Devices (any device with the date filled in) | Info at 365 days, Warning at 180, Failing at 90 and once past | | Developer mode | Whether the Chromebook booted in developer mode | Google Devices | Failing | | Disk nearly full | How full each volume is | All four | Warning at 80% used, Failing at 90% | | Not checking in | When the device last contacted its MDM | All four | Warning after 14 days, Failing after 30 | | Not enrolled | Whether the MDM still manages the device | Google Devices, Jamf Pro | Failing | | OS behind | The device's OS version against your target, or the newest in your fleet | All four | Warning 2 releases behind, Failing at 4 | | Battery wearing out | Battery health as a share of new | Jamf Pro, Mosyle, Intune | Warning at 80% health, Failing at 60% | | Disk not encrypted | FileVault or BitLocker | Jamf Pro, Intune | Failing | | Warranty expiring | The device's Warranty Expiration date | Any synced device with the date filled in | Info at 90 days, Warning at 30 and once past | | Chromebook battery | Google's battery verdict and a full charge as a share of design capacity | Google Devices, with Chrome Management telemetry | Warning at 80% of design capacity, Failing at 60% | | OS update not applied | Whether a downloaded Chrome OS update is waiting for a restart | Google Devices, with Chrome Management telemetry | Warning after 3 days, Failing after 7 | | Low memory | Free memory when the device last reported | Google Devices, with Chrome Management telemetry | Info below 10% free, Warning below 3% | | Running hot | The hottest processor sensor when the device last reported | Google Devices, with Chrome Management telemetry | Warning at 85 °C, Failing at 95 °C |

The four telemetry checks read Google's Chrome Management telemetry, which the Google Devices sync brings in beside the device record. It needs the telemetry reporting policy on in the Google admin console for the devices' organizational units, and a Google connection made after schoolOS started asking for it: an older connection shows Reconnect for telemetry on Admin › Account › Integrations under Google Devices, and the checks read Not checked until then. What it reports shows on the device's MDM section under Chrome Management Telemetry.

Where each level starts#

Each check draws its lines its own way, with the numbers on this page where it has them. A device is at the most severe level it has reached.

| Check | Info | Warning | Failing | | --- | --- | --- | --- | | Support ending | Support ends within the Info days (365) | Within the Warning days (180) | Within the Failing days (90), or has already ended | | Developer mode | One level, Failing to start with | | Google reports a developer boot mode | | Disk nearly full | Off to start with | Any volume is at or past 80% used | Any volume is at or past 90% | | Not checking in | Off to start with | No contact for 14 days | No contact for 30 days. A device in storage, in repair, missing or retired is never checked | | Not enrolled | One level, Failing to start with | | Deployed, but Google has it deprovisioned, disabled, inactive or delinquent, or Jamf has it unmanaged | | OS behind | Off to start with | 2 major releases behind the target | 4 releases behind. The target is the version you set, else the newest your fleet reports | | Battery wearing out | Off to start with | Health at or below 80% | At or below 60% | | Disk not encrypted | One level, Failing to start with | | FileVault or BitLocker is off | | Warranty expiring | The warranty ends within 90 days | Within 30 days, or has already ended | Off to start with: an expired warranty is a cost, not a broken device | | Chromebook battery | Off to start with | A full charge holds 80% or less of design capacity, or Google says replace it soon | 60% or less, or Google says replace it now | | OS update not applied | Off to start with | An update has waited 3 days for a restart | 7 days | | Low memory | 10% or less of memory was free at the last report | 3% or less | Off to start with | | Running hot | Off to start with | The hottest sensor read 85 °C or more | 95 °C or more |

A check that can't read what it needs (no date on the asset, no battery figure from the MDM) is Not checked, never a failure. Each level's own action decides what happens when a device reaches it.

Support ending#

Info at 365 days before the device's Support End Date, Warning at 180, Failing at 90 and once the date has passed. For a Chromebook the date is Google's Auto Update Expiration, filled in by every Google Devices sync; see Support End Date. A typical setup notifies the refresh-planning team at Info and the building techs at Warning, and leaves Failing to open a ticket. A device with no date isn't checked.

Developer mode#

Fails when Google reports the Chromebook booted in developer mode, which lets a student bypass policies. A yes/no check has one level: it starts at Failing, and you can make it a Warning or an Info instead.

Disk nearly full#

Warning when any volume is 80% full, Failing at 90%. Google reports each volume; Jamf each partition; Intune and Mosyle the whole disk. A device whose MDM doesn't report storage shows Not checked.

Not checking in#

Warning after 14 days without a check-in, Failing after 30. It reads the MDM's own last-contact time, not when schoolOS synced. Devices your account has in storage, in repair, missing or retired are skipped: a Chromebook in a summer cart isn't lost.

Not enrolled#

Fails when Google or Jamf says the device is deprovisioned, disabled or unmanaged while schoolOS still has it deployed, so policies no longer reach it. A device your account has in storage, in repair, missing or retired passes: it isn't expected to be enrolled. One level, Failing to start with.

OS behind#

Compares the device's major OS release to a target. Set Target OS version to the release your fleet should be on (like 130 for ChromeOS, or 15 for macOS); leave it blank and the check uses the newest release any of your devices on that MDM reports. Warning 2 releases behind, Failing at 4.

Battery wearing out#

Warning when the battery holds 80% or less of its design capacity, Failing at 60%, for the devices that report it (Macs and iPads through Jamf or Mosyle; Windows devices through Intune). Chromebooks have their own check below.

Disk not encrypted#

Fails when Jamf reports FileVault off, or Intune reports the device not encrypted. A lost device with its disk unencrypted can have its files read, so this is one most districts set to open a ticket.

OS update not applied#

Chrome OS downloads updates on its own and applies them at the next restart. A device that's never restarted runs without the fixes it already has. The check counts a device as waiting while Google reports the update downloading or waiting for a restart; a device with no update to install passes. It counts days since Google last checked for the update (or since the last restart when that's unknown): Warning after 3 days, Failing after 7. A restart clears it.

Low memory#

Free memory at the device's last telemetry report, as a share of what it has: Info at 10% free or less, Warning at 3%. Chromebooks with 4 GB run close to the edge with many tabs; a device that's always under the line is a candidate for replacement or a reminder to close tabs. It starts at Info because a single busy moment isn't a fault.

Running hot#

The hottest processor sensor at the last report: Warning at 85 °C, Failing at 95 °C. Chromebooks throttle around 85 °C and shut down near 100 °C; a device that reads hot every day usually has a blocked vent or a failing fan.

Warranty expiring#

Info at 90 days before the device's Warranty Expiration date, Warning at 30 and once it has passed. It never fails by default: most districts want a report, not a ticket. A device with no date isn't checked.

Levels#

A check that measures something (days, a percentage, releases, degrees) has up to three levels, each on or off:

| Level | What it means | Where it shows | | --- | --- | --- | | Info | A heads-up: worth knowing, nothing to do yet. | Quietly, in blue, on the device's page, in the Health column and in reports. | | Warning | Needs a look soon. | In amber on the device, in the Health column and in digests. | | Failing | Needs attention now. | In red; counts as failing in reports and in Otto's answers. |

Each level starts at its own number, in the check's own unit: days before support ends, % used, days without a check-in. A more severe level always starts past a milder one (fewer days left, more percent used), and the page says so when they're out of order. A device is at the most severe level it has reached; the check's one result is that level, so a Chromebook 60 days from its support end is Failing, not Info and Warning and Failing at once.

A yes/no check (developer mode, not enrolled, disk not encrypted) has one level. It starts at Failing; make it a Warning or an Info when that's all it should be in your district.

What happens when a check fails#

Each check has its own settings on this page. Open a check to change them, then Save.

• Run this check. Turn it off and its results are no longer updated; devices keep whatever it last found.
• Levels. Each level you keep on has a number it starts at and what happens then: Record it only, Notify a team or Open a ticket. Turn a level off to skip it. The action fires when a device reaches that level, or climbs to it from a milder one; a device that steps down (from Failing back to Warning after a new support date) fires nothing until it passes again.
• Team. For Notify a team: each member gets one notification and one email per run listing every device that reached the level or recovered, never one per device. People who turn off Device Health under their notification settings get neither. A recovery goes to the team that heard about the level the device was at.
• Department and Topic. For Open a ticket: where the ticket is filed. Leave the department unset to use your account's default department. The topic gives the ticket its team, priority and SLA, as any ticket on that topic.
• Close the ticket when the device recovers. On by default. When the check passes again the ticket is solved with a note, unless someone has already replied on it; then it only gets the note.

One ticket per device and check: while that ticket is open, no level opens another, whichever one opened it. The ticket links the device, its location, and the observed value, says which level the device reached, and points at the device's Device Health section.

Which action should I choose?#

| Option | What it does | Choose it when | | --- | --- | --- | | Record it only | The result shows on the device's page, in the Health column and in reports. | You review health from the Assets list or a report, or you're trying a level out before it makes noise. | | Notify a team | One digest per run to a team's members, by bell and email. | Someone should know, but a ticket per device would be too many: warranties, support ending, OS behind. | | Open a ticket | A ticket on the device in a department and topic, closed when it recovers. | Each failure is a job for a technician: developer mode, not enrolled, disk not encrypted. |

A middle school with a 1:1 Chromebook program sets Developer mode and Not enrolled to open tickets in IT under a "Chromebook policy" topic, and on Not checking in notifies the building techs' team at Warning and opens a ticket at Failing. On Support ending it notifies the technology director's team at Info (a year out, for the refresh budget), the building techs at Warning (six months out, to plan the swap), and opens a ticket at Failing. A district with a Mac lab sets Disk not encrypted to open a ticket.

A device's health#

A device matched to an MDM record has a Device Health section on its page (the heart icon in the right rail), which a health ticket or digest links to. At the top, one chip per status says how many checks are there: 2 failing, 1 warning, 9 passing. Select a chip to open those checks and jump to the first. Beside the chips are the device's worst status with how many checks are at it, its owner, which tool reports it, its last sync and last check-in, and Re-check now, which runs every check again on the data already synced.

Under that, every check that applies to the device, worst first, each with its status drawn at the left: a red circle for failing, an amber triangle for warning, a blue mark for info, a green check for passing. A check at a level starts open, showing what it found, since when, View ticket when one is open, and Snooze; a passing check is folded to one line, with its reading, and opens when you select it. Then the facts the checks read, grouped as the MDM reports them, and a history of each change of status.

When no check needs attention a green banner says All health checks passing. When the MDM hasn't synced in two days the section says the data may be out of date and when it last synced.

Snooze quiets one check on one device for 1, 7, 30 or 90 days: the check keeps running and the page keeps showing its result, but no ticket is opened and no digest mentions it until the snooze ends. Stop snoozing ends it early. Snoozing needs Manage device health; seeing the section and re-checking need View device health.

On the Assets list#

A device that's failing or warning carries a dot on its picture in the list, red or amber, with the summary when you hover it, so you see it without turning on a column; an Info level stays off the picture. The Health column (hidden to start with; turn it on under Columns) shows each device's worst status, with how many checks are at it. It's the same answer the device's own Device Health section gives: only checks that are on and that apply to the device's MDM count, and a check that's Not checked never sets it. A device reads Not checked only when none of its checks has a reading. Two filters under Device Health find devices by it: Device health (Passing, Info, Warning, Failing, Not checked, or No health data for a device with no results yet) and Health check needing attention, which lists the checks and finds devices where that check is at any of its levels. Both work in saved views and in Export to CSV, which adds Health and Failing Health Checks columns. A digest's link opens the list filtered to failing devices.

Device Health also feeds schoolAutomate: a workflow can start when a check reaches a level (or a worse one) on a device, and when it passes again.

Reports and Otto#

Insights has two Device Health datasets for anyone who can open this page: Device Health (one row per device per check: its current result, with Failing Checks, Warning Checks and Info Checks to count by level, the device's school, type, model and assignee, whether it has a ticket, whether it's snoozed) and Device Health Changes (each time a check's status changed, for trends). The Devices tab's Device Health section starts with devices failing a check, failing checks by check, results by status, devices failing by school, open health tickets, failures by week, failures against recoveries by month, and devices losing support by school year (from each device's Support End Date and your account's fiscal year). Reports count only the devices you see on the Assets list.

Ask Otto "which devices are failing a health check", "how many devices are not checking in" or "devices with their disk nearly full by school", and it answers from the same devices, with View as list to open them on the Assets list and Open as report when the report counts exactly those devices.

Who can do what#

View device health sees a device's health, the Health column and filters, and re-checks a device. Manage device health also changes these settings and snoozes checks. Both come with the schoolAssets devices feature; an account without it has no Device Health page.

schoolOS staff have no account of their own, so the settings page asks them to pick one at the top right. Until they do, the checks show their defaults and can't be saved. The settings page opens with At a glance, one line per check with the levels it keeps and what they do; select a line to open that check's settings.