Extended Device Uptime Insight

The Extended Device Uptime insight identifies devices that have not had a full OS restart within the configured period. While Windows is designed to run continuously, periodic restarts are essential for applying operating system updates, refreshing system resources, and ensuring that driver and configuration changes take effect.

Devices that go too long without a restart accumulate pending updates that never apply, experience gradual performance degradation from memory overhead, and carry a higher risk of instability. This insight gives administrators visibility into which devices are overdue for a restart — before users notice the effects.

This insight helps administrators:

• Identify devices that have not had a full restart and may have pending updates not yet applied
• Detect devices where users rely on sleep or Fast Startup shutdown instead of restarting
• Enforce restart compliance across the fleet, particularly after Patch Tuesday deployments
• Reduce performance degradation caused by long-running system state accumulation

Trigger Conditions

The Extended Device Uptime insight is generated when:

• Last boot is older than 7 days. The device has not had a full OS restart in more than one week.
• Threshold values can be customized based on organizational restart policies.

Accessing the Insight

1. In DEX Manager Plus, click DEX in the top navigation bar.
2. Select Insights from the left sidebar.
3. Locate the insight: Extended uptime detected, performance and updates may be affected.
4. Click the insight name to open the detail view.

Interpreting the Insight Metrics

The insight summary bar shows four cards. Notably, the fourth card shows the Fast Boot Enabled device count — not a storage or location metric. This directly connects extended uptime to its most common cause.

Understanding the metrics

The summary cards help identify whether the issue is tied to a specific hardware segment or whether it is driven by a configuration pattern such as Fast Startup.

Analyzing Affected Devices

The device table shows per-device uptime data with actual readable timestamps — giving a clear picture of when each device last had a full restart and whether Fast Startup is responsible for the accumulated uptime.

Understanding the columns

The device table provides detailed visibility into uptime duration, boot history, Fast Startup status, and telemetry freshness.

Root Cause Investigation

In this insight example, the root cause is immediately clear: all 5 affected devices have Fast Boot Enabled: Yes. The investigation is confirming this pattern and determining the right policy response.

Remediation

Force a Restart on affected devices and determine whether Fast Startup should remain enabled or whether a scheduled restart policy should be enforced.

Post-Remediation Monitoring

1. Return to DEX > Insights and verify that impacted device counts decrease.
2. Confirm that affected devices show recent restart timestamps.
3. Verify pending updates have applied successfully.
4. Monitor for recurrence and adjust restart policies if necessary.

Configuring the Uptime Threshold

1. Navigate to DEX > Insights.
2. Locate the Extended Device Uptime insight row.
3. Click the edit icon (pencil) next to Last boot older than 7 days.
4. Update the number of days and save.

Frequently Asked Questions

Why does a device show 10 days uptime if the user shuts it down every evening?

Because Fast Startup is enabled. When a user clicks Shut Down with Fast Startup active, Windows saves the kernel session to disk and restores it on the next boot — the OS considers the device to have been running continuously. The Days Since Last Boot counter does not reset on a Fast Startup shutdown. Only a full Restart resets it. In this example, all 5 affected devices have Fast Boot Enabled: Yes — confirming this is exactly what is happening.

What is the difference between Last Boot Start Time and Last Boot End Time?

Last Boot Start Time is when the boot process began. Last Boot End Time is when it completed. When Fast Startup is enabled, the End Time may reflect when the previous session state was saved to disk rather than a linear completion of the most recent boot — which is why it can appear earlier than Last Boot Start Time. Verify with the development team how these timestamps are defined before relying on this column for diagnostics.

Does a Restart always reset the uptime counter?

Yes — a Restart (not Shutdown) always performs a full cold boot and resets the Days Since Last Boot counter to zero. Only a Restart triggers full update application and kernel re-initialization. A Shutdown with Fast Startup enabled does not reset the counter.

Should I disable Fast Startup fleet-wide?

Not necessarily. Fast Startup is a legitimate feature that improves user experience by making daily startups faster. The recommended approach is to keep Fast Startup enabled but enforce a weekly scheduled Restart via Configurations — this gives users faster daily startups while ensuring updates apply reliably at least once a week. Disable Fast Startup only if the weekly Restart policy cannot be enforced, or if you are in a security-sensitive environment where every shutdown must produce a full cold boot.

Should I review this insight alongside other insights?

Yes. Extended Device Uptime is directly linked to the Fast Startup Enabled insight — devices appearing in both need a policy decision on Fast Startup, not just a one-time restart. Also cross-reference with Slow Boot Time: if a device has high uptime and also shows slow boot, users may be avoiding restarts because the boot takes too long. Fixing the boot time (SSD upgrade, reducing startup apps) can improve restart compliance by reducing the friction of restarting.