Only alerts that stay open become tickets. DaemonLayer investigates, fixes with scripts you approved, verifies the fix, or hands a technician a ticket that is already half-solved.
Fewer tickets, better tickets
RMM alerts are the noisiest source of tickets an MSP has. DaemonLayer sits between your RMM and your PSA and makes sure each alert ends up where it belongs. Datto RMM today, more vendors coming.
An alert has to stay open for a grace period (10 minutes by default) before it becomes a ticket. Most alerts clear themselves, and those never reach your PSA or your usage.
When a script you approved fits the problem, a technician approves the run, DaemonLayer runs it through the RMM, then re-checks the alert. Only a cleared alert closes the ticket in DaemonLayer, your PSA and the RMM.
Anything risky, recurring or uncertain goes to a technician with one internal note: why it escalated, what automation already found, and suggested first checks grounded in your history.
RMM Alert Triage
A surviving alert becomes a DaemonLayer ticket and a PSA ticket for the linked client. Then the RMM Alert Triage workflow does the first ten minutes of a technician's work.
Muted alerts and alerts from RMM sites that aren't linked to a client are dropped. A repeat of a monitor that already has an open ticket is added to that ticket as a note, not raised as a new one.
Priority follows the alert's severity: Critical becomes High, Warning becomes Medium, everything else Low.
DaemonLayer reads the device's alert history for the last 30 days and finds similar past tickets, including how they were fixed.
If more evidence helps, it may run up to two scripts you marked as Diagnostic, such as an event log query. Diagnostics can't change anything on the device.
It escalates when unsure, and prefers a technician over a risky fix: hardware errors, or the same monitor failing on several devices (likely a shared cause). Either way, an internal PSA note records the diagnosis, decision, rationale and confidence.
RMM Remediation
A fix isn't done when the script finishes. It's done when the alert is gone.
Code confirms the script is still allowed and the device is online. A technician gets an approval card with device, script, parameters, diagnosis, rationale and confidence.
The script runs on that device through the RMM. One remediation attempt per ticket; a second problem goes to a technician.
After a configurable delay (15 minutes by default) the alert is checked again. Cleared: closed in DaemonLayer, the PSA and the RMM. Still open: handed to a technician.
Scripts on client devices are the scariest thing an automation tool can do, so DaemonLayer starts with nothing. Each script is Disabled until you set it to Diagnostic (read-only) or Remediation (approval) and write when the agent should use it. The AI only chooses from that list, and the checks that matter run in code, not in the AI.
RMM Handoff
When automation stops, the technician gets one internal note instead of a raw alert. The top of the note is built from ticket history, not AI, so it is useful even if the AI step fails.
Recurring alert, hardware error, several devices affected, a failed verification or low confidence. The reason is stated up front.
Alert history, diagnostic results and similar past tickets with how they were fixed, so nobody repeats the same checks.
Advisory AI suggestions grounded in past tickets and your client documentation, with verified references. Links that don't come from your documentation are stripped.
Learns From Every Fix
Every closed alert ticket records what fixed it, for example "Fixed by running Start Windows Service" or "Cleared by the RMM without intervention". Future triage on the same monitor sees that history and proposes the fix that has actually worked.
All thresholds are yours to tune per connection: the grace period, how many repeats count as recurring, the recurrence window and how long to wait before verifying.
FAQ
Datto RMM today, with more vendors coming. The workflows are vendor-neutral, so the grace period, the script allow-list and every safety check work the same way for each RMM we add.
Because most alerts clear themselves. An alert has to stay open for a grace period (10 minutes by default) before it becomes a ticket. Alerts the RMM clears in the meantime never reach your PSA.
No. Reboot and shutdown scripts are on a hard block list along with uninstall, wipe or format, removing users, BitLocker, disabling networking and anything that can expose secrets. They cannot be enabled, whatever you configure.
No. An alert counts once it becomes a triaged ticket. Alerts cleared during the grace period, muted alerts and repeats added to an existing ticket do not count.
Related
Connect your PSA, and DaemonLayer starts triaging, resolving, and routing, no scripting, no setup calls. Cancel anytime.
Prefer a walkthrough? Book a demo →
