Rule out the big causes first — site outage, maintenance, decommission — then reconstruct
what happened from the device activity and give the tech precise on-site guidance or an
escalation. Needs the RMM connected; without it, fall back to ticket history and
documentation and say the RMM view was unavailable (Connector Degradation base skill).
1. Resolve the device: organization first, then look it up. Rank candidates by organization
match, then most recent last-contact, and state your pick. Confirm the class in the
device details, not from a filter.
2. Site-wide check FIRST. Pull the organization's other devices. Several at one site
dropping around the same time is a network or site outage, not a device problem — say so
and switch to Network Outage Triage.
3. Maintenance next. In a window, or one recently set? Offline inside planned maintenance
is not an incident — note it and stop, unless the window has expired.
4. Build the timeline: exact last-contact from the device details, then recent activity for
what happened just before it dropped — shutdown, reboot, agent update, logoff, patch.
Repeated offline/online pairs in the alert history mean a flapper, pointing at NIC, power
or Wi-Fi rather than hard failure.
5. Classify: clean shutdown before the drop means powered off; patch or reboot activity means
hung during restart; nothing preceding means power, network path or hardware; last contact
weeks ago means possibly retired.
6. Cross-check documentation and recent tickets — scheduled for replacement, reimage or
decommission? Recent remote-session activity means another tech is on it: coordinate.
7. If it looks local or power-related, give concrete physical checks: power and LEDs, cable
or Wi-Fi association, whether the machine responds locally, power-cycle guidance. You
cannot see a powered-off machine — say what only on-site eyes can confirm.
8. Escalate when it is a server or shared infrastructure, hosts services others depend on,
has been offline past the client's tolerance with no explanation, or the checks fail.
Hand over the timeline, evidence, checks done, and next-tier steps.
Never mark an offline alert resolved just because the device came back — confirm stability
first, and closing is the requester's call. Distinguish "confirmed" from "likely" and claim
no cause you can't evidence. A long-offline device is flagged "verify still in service", not
worked as an incident. Offer the diagnostic as a note (PSA Note Discipline base skill).
As a Flow: your entire reply is the note. Input is the device id from the triggering alert —
never guess by name unattended; unresolvable device or no RMM means output nothing. Lead with
"PROBABLE SITE OUTAGE - not a device issue" and skip the per-device work when the site
dropped together; emit exactly "IN MAINTENANCE WINDOW - NO INCIDENT" inside a window. The
note is the only permitted write — never resolve or close the alert or ticket.
Magic Library