DaemonLayer Logo
Datto RMM

Monitoring alerts stop being noise

Only alerts that stay open become tickets. DaemonLayer investigates, fixes them with scripts you approved, verifies the fix, or hands a technician a ticket that is already half-solved.

alert
Critical
Service "Windows Update" stopped · LAP-0142
step
Grace period · still open after 10 min
Cleared meanwhile → no ticket
agent
RMM Alert Triage
30-day historySimilar fixesEvent log (read-only)
approval
Approved
Run "Start a Windows service" · wuauserv
verified
Alert cleared after 15 min · closed in PSA & Datto

Datto RMM Capabilities

Connecting your RMM gives DaemonLayer three things: alerts it can work, devices it can check, and scripts it may run. Fewer tickets, and better ones.

Alert Handling

Alerts arrive with history, diagnostics and a proposed fix

An alert only becomes a PSA ticket once it has stayed open for the grace period. DaemonLayer then checks the device's last 30 days of alerts, finds similar past tickets and how they were fixed, and can run up to two read-only diagnostics, such as an event log query, before it decides.

  • Priority follows severity: Critical → High, Warning → Medium, everything else → Low
  • A repeat of a monitor with an open ticket is added as a note, not a new ticket
  • Recurring alerts are never auto-fixed: same monitor, same device, 3× in 7 days goes straight to a technician
  • Learns from every fix: "this monitor was fixed by that script 4 times before"
How RMM alert handling works
RMM Alert TriageCritical → High
Service "Windows Update" stopped
LAP-0142 · Nordic Systems · open for 12 min
Alerts on this monitor, last 7 days1 of 3 allowed
Same monitor on other devicesNone
Event log query (read-only)Service crash, 2 events
Past fixes
Fixed by "Start a Windows service" 4× before at this client
Decision · confidence 0.91
Remediate with an approved script, then verify the alert clears.
Device Troubleshooting

"I can't open PDFs" — checked and fixed on the user's own device

For problems local to the user's own Windows computer, DaemonLayer finds their device, searches its installed software, optionally runs a diagnostic, and picks a fix from the scripts you allowed. A technician approves it, the script runs, and the user is asked to try again.

Only offered when it can actually help: a device is found, a script is allowed, and the problem is on the device— not accounts, licences, M365 or the network.

How device troubleshooting works
Device TroubleshootingResolved
Emma Northbridge
"I can't open PDFs on my laptop."
Software audit · LAP-0142
No PDF reader installed
Technician approved
Adobe Acrobat Reader install
Message to user
"We started an installation of Adobe Acrobat Reader on your computer (LAP-0142). Please try again in about 10 minutes and reply."
Emma Northbridge
"Works now, thanks!"
Device Context

Triage sees that user's devices, and only theirs

When a user reports a problem, triage sees their devices: hostname, operating system, online state and last seen. Technicians stop asking "which computer?", and DaemonLayer never shows or acts on a client's whole device fleet because a user asked.

No manual mapping: devices are matched to users automatically.

Devices for this reporter
JR
James Ritter
LAP-0142
Windows 11 Pro · last seen 2 min ago
Online
DESK-0087
Windows 10 Pro · last seen 3 days ago
Offline
Matched by
Login historyEntra device ownerSign-in activity
How it fits together

Every path ends in a verified fix or a technician

An alert that became a ticket is never silently dropped. If DaemonLayer can't prove it fixed the problem, a person gets it.

RMM Alert Triage

Waits out the grace period, creates the PSA ticket, checks 30 days of alert history and similar past tickets, and may run up to two read-only diagnostics before it decides: fix or technician.

RMM Remediation

Re-checks in code that the script is still allowed, asks a technician to approve, runs it through Datto, then verifies the alert actually cleared before anything is closed.

RMM Handoff

When automation stops, the technician gets one internal note: why it escalated, what was found, suggested first checks from past tickets and your documentation.

Device Troubleshooting

For user tickets about their own Windows computer. Checks installed software and diagnostics on that device, proposes an approved fix and asks the user to confirm it worked.

RMM Handoff

When it shouldn't fix, it hands over a ticket that's half-solved

DaemonLayer prefers a technician over a risky fix. Hardware errors, the same monitor failing on several devices (likely a shared cause), recurring alerts or low confidence all go to a person, with one internal note that explains what automation already did.

  • The top of the note is built from ticket history, not AI, so it is useful even if the AI step fails
  • Suggested first checks are grounded in similar past tickets and your Hudu documentation
  • Links that don't come from your own documentation are stripped
Internal notePSA ticket #260412.0031
Why it escalated
Disk Usage on SRV-FS01 alerted 3× in 7 days. Recurring alerts are not auto-fixed.
What automation found
D: at 94%. Previous two tickets closed after temp-file cleanup; usage returned within 48 h.
Suggested first checks
AI · advisory
  1. Check which share grew since the last cleanup
  2. Review the file server retention procedure
References
Hudu · File server retention (Nordic Systems)
#260329.0012, #260405.0007
Control & Safety

Scripts on client devices are scary. So nothing runs until you allow it.

Every Datto component starts Disabled. You allow scripts one by one, write when the agent should use each one, and the AI only picks from that list. The checks that matter run in code, not in the AI.

Hard block list, whatever you configure
Reboot or shutdown, uninstall, wipe or format, remove users, BitLocker, disabling networking, and anything that can expose secrets can never be enabled.
Safety checks in code, before every run
Script still allowed, device online, no unsupported inputs required, alert still open, and one attempt per ticket.
Technician approval on every fix
With HITL on RMM Remediation (recommended), the approval card shows device, script, parameters, diagnosis, rationale and confidence.
A user only ever sees their own devices
DaemonLayer never lists or acts on a client's whole fleet because a user asked. Servers are never linked to users automatically.
Audit trail without secrets
Every run is logged with device, script and parameter names. Never parameter values or script output, which can contain secrets.

DaemonLayer never reboots, deletes or reconfigures Datto itself.

Scripts the agent may runDatto RMM
Event log query
"To see recent errors when a service stops or crashes"
Diagnostic
Start a Windows service
"A monitored service is stopped; use the service in the alert"
Remediation
Install software · Adobe Acrobat Reader
"No PDF reader and the user can't open PDFs"
Remediation
Map network drives
Not allowed
Disabled
Reboot device
Always blocked: reboots or shuts down a device
Blocked
BitLocker recovery key export
Always blocked: BitLocker, can expose secrets
Blocked
Software installs can be Remediation, never Diagnostic
Automatic device matching

Whose laptop is LAP-0142? DaemonLayer works it out.

Devices sync every hour. DaemonLayer links devices to users from several exact-match signals, so there is no mapping spreadsheet to maintain. Admin and built-in accounts never link a device to anyone, devices not seen for 90 days are ignored, and re-imaged duplicates resolve to the most recent.

Technicians can review every link on the client's Devices tab and set a manual override when they want to. An override always wins and never expires.

Connecting Microsoft 365 makes device matching much more reliable
SignalNeeds M365
Login history: everyone seen on the device, not just the last userNo
On-prem username to email (DOMAIN\jdoe → email)Yes
Entra device ownerYes
Sign-in activity, last 30 days (also hybrid-joined devices)Entra ID P1
Hostname written in the ticket, e.g. "LAP-0142"No

Live in about 5 minutes

Create an API key, connect, allow your scripts. DaemonLayer works through the Datto agent you already run; there is no DaemonLayer agent to deploy.

  1. 01
    Create an API key

    Enable API access in Datto RMM and generate a key and secret for a dedicated DaemonLayer user.

  2. 02
    Connect

    Pick your Datto region, paste the key and secret, and test. Sites whose names match your clients are linked automatically.

  3. 03
    Allow scripts

    Every component starts disabled. Allow the ones you trust, write when to use them, and switch on the workflows.

Recommended starter set
Diagnostic
Event log queryDisk space reportService status check
Remediation
Install software (PDF reader, browser)Reset default apps / file associationsStart a stopped Windows serviceClear temp files & cachesRepair Microsoft 365 Apps

Start with diagnostics: they are read-only and make every decision better. Use whatever components you already run in Datto; these are common starting points.

Frequently Asked Questions

Common questions about this integration

Which RMM platforms does DaemonLayer support?

Datto RMM today, with more vendors coming. The RMM integration is vendor-neutral by design: alert handling, device context, the script allow-list and every safety check work the same way for each RMM we add.

Will every Datto alert become a ticket?

No. An alert has to stay open for a grace period (10 minutes by default) before it becomes a ticket. Most alerts clear themselves and never reach your PSA. Muted alerts and alerts from Datto sites that aren't linked to a client are dropped, and a repeat of a monitor that already has an open ticket is added to that ticket as a note.

Can DaemonLayer reboot devices or uninstall software?

No. Scripts that reboot or shut down a device, uninstall software, wipe or format, remove users, touch BitLocker, disable networking or can expose secrets are always blocked. They show a lock icon and cannot be enabled, whatever you configure. DaemonLayer also never reboots, deletes or reconfigures Datto itself.

Which scripts can DaemonLayer run?

Only the Datto components you explicitly allow, one by one. Every component starts Disabled. You can set it to Diagnostic (read-only, used to gather evidence) or Remediation (used to fix, with technician approval when HITL is on), and you write the guidance for when the agent should use it. The AI only picks from that list.

What happens after a fix runs?

DaemonLayer re-checks the alert after a configurable delay (15 minutes by default). If it has cleared, the ticket is closed in DaemonLayer, your PSA and Datto. If it is still open, the ticket goes to a technician. Each ticket gets one remediation attempt; a second problem always goes to a person.

Do we have to map users to devices manually?

No. Devices sync every hour and DaemonLayer works out who uses which device from exact-match signals such as login history and, with Microsoft 365 connected, Entra device owner and sign-in activity. Technicians can review the links and set a manual override, but it is optional.

Does an alert count towards our ticket volume?

Only once it becomes a triaged ticket. Alerts that clear during the grace period, muted alerts and repeats added to an existing ticket do not count.

Automate your first ticket in under 30 minutes

Connect your PSA, and DaemonLayer starts triaging, resolving, and routing, no scripting, no setup calls. Cancel anytime.

Prefer a walkthrough? Book a demo →