Scope, Intended Behavior, and Recommended Alternatives
Overview
In Datto RMM, the reboot.flag file is a system‑generated indicator used by the platform to determine whether a managed endpoint requires a reboot. Its creation and handling are tightly coupled with patching workflows and patch policy configuration. While partners may attempt to manually create this file to influence reboot behavior, this approach falls outside of supported and documented use.
This article clarifies:
- What the
reboot.flagfile is intended to do - Why manual creation leads to inconsistent or undefined behavior
- How reboot prompts are actually triggered
- What internal product experts recommend instead
Official Documentation
Datto documentation confirms that reboot.flag is part of the agent’s reboot detection logic and is not documented as a manual control mechanism:
- Datto RMM Agent Troubleshooting – Reboot.flag
https://rmm.datto.com/help/en/Content/Troubleshooting/Agent/KB370000002132.htm
What the reboot.flag File Is Designed to Do
The reboot.flag file is automatically created by Datto RMM under specific circumstances when the platform determines that a reboot is required—most commonly following patch execution.
Key points:
- The file is not designed for manual creation
- Its presence alone does not guarantee a reboot prompt
- It operates in conjunction with patch policies and their configuration
When used as intended, the platform controls:
- When the reboot reminder is shown
- How often it reappears
- Whether users can dismiss or defer it
Why Manual Creation Is Unintended and Unsupported
Internal product experts have explicitly stated that manually creating reboot.flag is an unintended use of Datto RMM. Because the platform does not expect the file to be created outside its own workflows, the resulting behavior is undefined and inconsistent.
From a support perspective:
- There is no guaranteed or documented behavior when the file is manually created
- Outcomes may vary between devices and environments
- This scenario is considered out of scope for support
As a result, Datto Support cannot reliably troubleshoot or explain the exact timing or appearance of reboot prompts when this method is used.
How Reboot Prompts Actually Work
A reboot prompt is not triggered by reboot.flag alone. Internal technical clarification confirms that several patch policy prerequisites must be met for the reboot reminder to appear.
For a reboot prompt to display:
- A valid patch policy must be assigned to the device
- The patch policy must have run at least once (a “last run” timestamp must exist)
- The setting “Show reboot reminder prompt” must be enabled
- Reboot dismissal and re‑prompt options must be configured
Additional behavior is influenced by:
- Policy last run time
- Reminder interval configuration
- Prior user actions (dismissals or acknowledgements)
Without a valid patch policy and completed patch run, reboot.flag will only:
- Be reported during audits
- Mark the device as “Reboot required” in the UI
It will not trigger an end‑user reboot prompt on its own.
Why Testing Results May Vary
Partners who manually create reboot.flag often report inconsistent results across endpoints. This is expected because:
- The file is evaluated in the context of patch policy state
- Policy timing, configuration, and user interaction history differ per device
- The platform was not designed to interpret a manually inserted flag
In short, variation is not a defect—it is a by‑product of using the mechanism outside its intended design.
Internal Expert Recommendation
Internal product experts consistently recommend not manually creating reboot.flag. Instead, they advise using supported notification mechanisms when a custom or controlled user experience is required.
The most commonly suggested alternative is:
- Toast Notifications with a reboot action
While Toast Notifications differ visually from the native Datto reboot prompt, they:
- Are fully supported
- Provide predictable behavior
- Avoid undefined platform interactions
Use Case Example:
Partner Intent
A PN is managing endpoints running outdated versions of Windows 11 that no longer receive security updates. Because patches fail to install:
- No patching events complete
- Users are never prompted to reboot
- Devices remain in an insecure state
The PN attempts to manually create reboot.flag so that:
- Devices appear to require a reboot
- Users receive reboot prompts only during approved patching windows
- The native Datto reboot prompt is used to avoid user confusion
Why This Approach Is Problematic
- Manual creation of
reboot.flagis not supported - Reboot behavior depends on patch policy execution, not just file presence
- Results are inconsistent and cannot be reliably controlled
- Support cannot guarantee or troubleshoot outcomes
Internal Expert Recommendation
Internal experts recommend not using reboot.flag as a manual trigger. Instead:
- Ensure a valid patch policy is configured and executed where possible
- Use Toast Notifications with a reboot option to guide user action
- Accept that the native reboot prompt cannot be safely replicated outside its intended workflow
This approach aligns with platform design, ensures predictable behavior, and remains fully within supported use.
Summary
-
reboot.flagis system‑managed, not a manual control - Its behavior is undefined when created manually
- Reboot prompts depend on patch policy configuration and execution
- Toast Notifications are the recommended, supported alternative
- Scenarios involving manual
reboot.flagusage are out of scope for support