10.22. Turn RMM Alerts into Tickets: Alert Rules, Maintenance Windows, and Polling

An unwatched RMM alert is a client outage nobody is working. An over-watched one is a board full of duplicates that buries the real problem. Alert Automation solves both. Rules decide which alerts deserve tickets and where those tickets go. Duplicate protection keeps a flapping check from storming your board. Maintenance windows silence the noise you planned for. And when the alert clears in the RMM, AlgaPSA closes the ticket for you, unless a technician has already started working it.

The Alert Automation section appears at the bottom of each connected provider's settings panel (NinjaOne, Tactical RMM, and Level). Everything you configure there applies to that integration's alerts. Huntress uses its own routing configuration instead; see Huntress Integration.

Figure 1: Alert Automation lives at the bottom of the provider settings panel. One rule routes serious alerts to tickets, a weekly window covers Sunday patching, and polling backstops the webhook feed.

Alert rules

Rules are evaluated top to bottom. The first rule that matches an incoming alert wins. A rule with no match conditions is a catch-all, which makes a simple starting setup easy: one catch-all rule that creates tickets on your triage board.

Click Add rule in the Alert Rules card to open the editor.

Figure 2: A rule that matches critical and major alerts and creates a ticket on the default board. With no conditions set, the rule would act as a catch-all.

Match conditions

Every condition you set must match for the rule to fire. Leave them all blank to match everything.

Actions

• Create ticket is the main action. When enabled you choose:
  • Board — where the ticket lands. Defaults to your default board.
  • Priority override — a fixed priority, or leave it on Map from severity and AlgaPSA picks a priority whose name matches the alert severity (critical maps to a priority named like "Critical" or "Urgent", major to "High", and so on).
  • Assign to user — optional auto-assignment.
  • Ticket title and description templates — optional. Placeholders: {{device}}, {{message}}, {{severity}}, {{organization}}.
  • Notify users — team members who get an in-app and email notification when the rule creates a ticket.
• Auto-resolve ticket when alert clears — when the RMM resolves the alert, AlgaPSA closes the ticket, but only if nobody has touched it. You can pick the closing status.
• Reset alert when ticket is closed — when a technician closes the ticket, AlgaPSA resolves the matching alert in the RMM, so the two systems agree.

Use the up and down arrows on the rule list to reorder rules. Put specific rules above your catch-all.

One ticket per problem, not per alert

A failing check rarely fires once. AlgaPSA deduplicates alerts per device and condition: while a ticket is open for a given check on a given device, every repeat firing attaches to that ticket as an "Alert re-triggered" note with an occurrence count, instead of creating a new ticket. A disk check that flaps thirty times overnight produces one ticket with a visible history, and your dispatcher's board stays readable.

A different device firing the same check, or the same device firing a different check, still gets its own ticket.

Tickets close themselves, carefully

When the RMM reports an alert resolved and the rule has Auto-resolve enabled, AlgaPSA looks at the ticket before closing it:

• Untouched tickets close. No human comments, no time entries, no status changes — the alert came and went without anyone needing to act, so the ticket closes with a resolution note.
• Touched tickets stay open. If a technician commented, logged time, or moved the ticket, AlgaPSA adds the resolution note but leaves the ticket alone. Nothing closes out from under someone mid-investigation.

In the other direction, Reset alert when ticket is closed tells the RMM the problem is handled when your technician closes the ticket. If the RMM cannot be reached, the ticket still closes normally; the failed reset is recorded on the alert for review, never thrown at the technician.

Maintenance windows

Patch nights and planned reboots generate alerts you already expect. A maintenance window suppresses alerts that arrive while it is active: they are recorded, but no tickets are created and nobody is notified.

Click Add window in the Maintenance Windows card.

Figure 3: A weekly window covering Sunday 2:00–6:00 AM Eastern. Alerts that fire during the window are suppressed; anything still broken afterward surfaces on the next poll.

Suppressed never means lost. If a device is still alerting after the window ends, the next polling cycle picks it up and runs it through your rules, so a patch window cannot swallow a real outage.

Alert polling

Webhooks deliver alerts the moment they fire, but a webhook can be missed: a network blip, an RMM outage, a misconfigured action. Polling is the safety net. On the interval you choose, AlgaPSA fetches the RMM's active alerts and reconciles them:

• An active alert AlgaPSA has never seen is processed through your rules, exactly as if the webhook had arrived.
• An alert AlgaPSA ingested by polling that is no longer active in the RMM is resolved, and its untouched ticket closes.

The Alert Polling card appears for NinjaOne and Tactical RMM. Toggle Polling enabled, set the interval (5–60 minutes), and click Save polling settings. The schedule adjusts itself within a few minutes of saving; disabling polling stops the schedule the same way. Level relies on its automation webhooks plus the manual Backfill Alerts button; Huntress polling is configured in its routing panel.

A worked example

Harborview Dental Group runs on managed endpoints you monitor with Tactical RMM. You configure:

1. A rule "Critical and major server alerts" matching severities critical and major, creating tickets on the Support board, priority mapped from severity, notifying your dispatcher. Auto-resolve on, reset-on-close on.
2. A catch-all rule below it that creates tickets on a Monitoring triage board with no notifications.
3. A weekly "Weekend patch window" for Sundays 2:00–6:00 AM Eastern, scoped to this integration.
4. Polling every 15 minutes.

A disk fills on their file server Tuesday afternoon: a critical alert creates a Support ticket, the dispatcher is notified, and the repeat firings stack onto the same ticket as occurrence notes. Sunday's patch reboots fire offline alerts into the window and are suppressed. A service that genuinely died during patching is still alerting at 6:15 AM, so the poll surfaces it as a fresh ticket. When the technician closes it, Tactical's alert resets automatically.

Operational checks

• Fire a test alert and confirm the expected rule matched: right board, right priority, notification received.
• Re-fire the same check and confirm the existing ticket gained an occurrence note instead of a duplicate ticket appearing.
• Resolve the test alert in the RMM and confirm the untouched ticket closed. Repeat with a comment on the ticket and confirm it stayed open.
• After changing the polling interval, check the card shows your saved value and a recent Last polled time within two cycles.

Related topics

• How RMM Integrations Work in AlgaPSA — the shared model behind every provider
• Ticketing Settings — boards, statuses, and priorities your rules route into
• Notifications — manage the RMM alert notification category