[Updated] SCM Device Restart Incidents — False Positive Notification

[shpereira]

Original Post -SCM Device Restart Incidents — False Positive Notification 

Initial update at 9PM Apr 22, 2026 by AIOps engineering team

Updated April 26, 2026 by AIOps engineering team

Updated June 4, 2026 by AIOps engineering team

June 4 Update

The Device Restarted alert has been re-enabled in production as of June 4, 2026. Following extensive testing and validation, the underlying detection logic has been rebuilt to accurately distinguish user-initiated device restarts from unexpected system reboots.

Alerts going forward will only fire for genuine, non-user-initiated restart events. Alerts automatically clear once the affected device has maintained continuous uptime for 3 days. If you have any open support cases from the April false-positive event, those may now be closed.

April 26 Update

The cleanup of false-positive Device Restarted incidents is now substantially complete. This update also addresses notification emails that some customers received between April 24–26, which may have appeared to show new incident activity.

What Happened

Beginning April 16, 2026, a subset of customers received a high volume of "Device Restarted" incidents for firewalls and Panorama instances that had not actually restarted. These were false positives caused by a defect introduced in a recent update to the SCM alert evaluation engine. Affected devices remained fully operational throughout this period.

Current Status

The Device Restarted alert was disabled as of April 22, 2026. No new false-positive incidents have been generated since that date.

Between April 24–26, our team completed the removal of false-positive incidents from customer dashboards. If you received notification emails during this period, these reflect incidents being closed out — not new alert activity on your devices. The date shown in those emails indicates when the incident was resolved, not when a new issue was detected.

What You Should Do

• No action is required on your devices. All firewalls and Panorama instances are operating normally.
• If your SCM dashboard still shows an open Device Restarted incident from the April event, it will be cleared shortly.
• If you received a notification email between April 24–26, this was confirmation that a prior false-positive incident was being resolved — not a new alert.
• If you have an open support case related to this incident, our team will follow up directly with resolution status.

Thank you for your continued patience.

[amaynard]

Why are device restarts being treated a critical incidents?

IMO, the critical flag should only apply when the device goes down, but does not come back up within 15 min.

Calling everything critical (restarts, telemetry delay, ect) and sending alerts for every single firewall separately is causing alert fatigue among customers, and over alerting SOCs who may then disregard actual critical issues like CVE exposure.

[svenkatarama]

@amaynard,

The Device Restart flags the user's attention to scenarios in which the SCM AIOps detects that a box has come back after a non-user-triggered reboot. Once triggered, this monitors the box's stability and auto-clears after 3 days if no new restarts are observed. We anticipate that this gives the user a chance to investigate why a restart occurred.
A delayed telemetry scenario means that the SCM AIOps end is unaware of what is happening on the box - that defeats the purpose of monitoring the box in the first place. 

Both of these are serious stability issues that require attention, perhaps not for the SOC team, but for the NetSec admins who manage the availability & performance.

The incident framework allows for granular notification capabilities. Depending on your org, these kinds of incidents may not need to go to the SOC team if the SOC team is not interested.