All posts

Should RMM Alerts Create Tickets? Only When Someone Has to Act

The Vight Team6 min read

Picture the service board on a Monday morning. Most of what arrived overnight came from the RMM: a backup that warned and then finished, a laptop that went offline when its owner closed the lid, the same disk threshold on the same file server four times. The dispatcher spends the first hour closing them. Somewhere in that pile is the one alert that mattered, and it gets the same thirty seconds of attention as the rest.

So should RMM alerts create tickets in your PSA? Some should. Most shouldn't. The rule we would use: an RMM alert should open a ticket only when a person has to do something about it, and the RMM can't fix it on its own. Everything else belongs on a dashboard, in a digest, or in an automated fix that leaves a record without asking anyone to read it.

Why "every alert becomes a ticket" breaks

A ticket is a promise that someone will look at this, do something, and record what they did. An alert is a measurement crossing a line. When you turn every measurement into a promise, three things happen:

  • The board stops meaning anything. Techs learn that most RMM tickets close themselves or need nothing, so they skim all of them. Karl Palachuk made this point years ago in his alerting SOP: too many alerts and "you and your techs" stop paying attention to alerts at all (Small Biz Thoughts).
  • Your reporting gets worse. Ticket counts per client, response times and agreement profitability all include tickets nobody worked. A client looks expensive because their server flaps, not because they call.
  • Priority loses its meaning. Many monitors open tickets at an emergency priority by default. When half the P1s on the board are a single workstation that stopped checking in, a real outage has to compete with them.

A three-bucket test for RMM alerts

Sort every monitor you have into one of three buckets. Be honest about what your techs actually do when each one fires.

1. Fix it automatically, don't ticket it. If the response is always the same script (clear temp files, restart a stuck service, rerun a failed patch job), let the RMM run it. If you want a record for the client, use a create-and-close ticket so it shows in history without landing in anyone's queue. NinjaOne's ConnectWise integration, for example, offers both "Create a ticket" and "Create and close a ticket" as condition actions (NinjaOne docs).

2. Watch it, don't ticket it. Trends that need attention eventually but not today: a disk at 80 percent, a warranty expiring, a machine that missed one patch cycle. These belong in a weekly review or a client report, where someone looks at them on purpose.

3. Ticket it. A person has to act, the RMM can't do it alone, and waiting costs the client something. A server down, a failed backup that didn't recover on retry, a security detection on a machine, a disk that the cleanup script couldn't get under threshold.

The bucket depends on context, not the monitor name. "Device offline" on a domain controller during business hours is bucket 3. The same alert on a laptop at 7 p.m. is noise.

The integration settings that decide your noise level

Most of the alert noise MSPs complain about comes from a handful of integration settings left at their defaults. Check these in whatever PSA and RMM pairing you run:

  • Grouping repeat alerts. Datto RMM's Autotask integration can group alerts into a single ticket when they have the same issue on the same device within a time window you set. If the earlier ticket is already closed, a new one is created (Datto RMM help). If grouping is off, a flapping monitor opens a ticket every time it fires.
  • What happens when the alert clears. In the same Datto integration, the ticket is resolved when the alert resolves, but you pick the status, and in Autotask only the Complete status actually closes a ticket. NinjaOne lets you choose which ConnectWise status a ticket moves to when its condition resets. Get this wrong and you get cleared alerts sitting open on the board, which is exactly the "techs working on problems that no longer exist" failure Palachuk warned about.
  • Company mapping. NinjaOne requires each organization to be mapped to a ConnectWise company before tickets are created. A missing or wrong mapping is how alerts end up on your catch-all company, where nobody owns them.
  • Board and priority. Send RMM tickets to their own board or queue with a sensible default priority. Don't let monitors set emergency priority unless the bucket-3 test says they deserve it.

How to measure whether your alerts are too noisy

You don't need a new tool for this. Pull last month's RMM-generated tickets from the PSA and count:

  1. Closed with no time entry. Each one is an alert someone looked at and nobody worked. A high share means bucket-1 and bucket-2 alerts are leaking into bucket 3.
  2. Closed within an hour by the alert clearing. These are flaps. Raise the threshold, add a duration, or turn on grouping.
  3. Duplicates. More than one open ticket for the same device and issue.
  4. The real ones. Tickets where a tech logged work. This is the number your alerting should exist to produce.

Then go monitor by monitor, starting with the ones that produced the most tickets in pile 1. Move them to a script, a digest or off. Repeat next month. It is dull work, and it is the work that makes the board trustworthy again.

Where AI helps, and where it doesn't

AI won't fix a monitor set to fire at 70 percent disk. Thresholds, grouping and mapping are configuration, and they are yours to own. Where it helps is the judgment a dispatcher makes after a ticket exists: is this an outage or one machine, is this a duplicate, what does the tech need to know before opening it.

That is the part Vight handles inside ConnectWise, Autotask, HaloPSA and Syncro:

  • P1 alerts read the ticket's title and the notes from the customer and from monitoring tools. An automated alert that one device, server, firewall or internet circuit is offline is classified P2 at most, even for a domain controller, until a person reports business impact or the alert shows several servers at one site down. A later monitoring note saying the device is back counts as recovery. Only a real P1 sends an alert to Teams, Slack or email.
  • Deduplication finds tickets about the same issue for the same client, by exact title or by AI similarity, and closes the duplicate with an internal note naming the original.
  • Ticket briefs put the requester's devices on the ticket, and with ConnectWise Automate or ConnectWise RMM connected (in beta), whether each machine is online, its disk space, missing patches and recent alerts. An alert ticket with nothing for Vight to add gets no brief, so it doesn't clutter the ticket.

More on how this fits with your tools in PSA vs RMM: the seams where work gets lost and AI for MSPs.

Quick answers

Should every RMM alert create a ticket? No. Only alerts that need a person to act, and that the RMM can't resolve on its own, should open a ticket. Automate the routine fixes and review trends on a schedule.

How do I stop duplicate RMM tickets? Turn on alert grouping in the RMM's PSA integration so repeats on the same device and issue update one ticket, raise thresholds or add a duration on monitors that flap, and make sure a cleared alert moves its ticket to a closed status.

What priority should RMM tickets get? A default below your client-reported urgent tickets, with exceptions only for alerts that clearly mean business impact, such as a server down or a security detection. A single device offline is rarely a P1 on its own.

How do I know my alerting is too noisy? Count last month's RMM-generated tickets that were closed with no time entry. Those are tickets nobody worked. Start tuning with the monitors that produced the most of them.

If your board is already full of RMM tickets and you want to see how Vight sorts the real incidents from the rest, book a demo and we'll walk through it on your own PSA.