This report crosses Datto RMM alert data (135,387 alerts), N-able backup statistics (169 active devices, 92.9% success rate), and Autotask ticket data (67,521 tickets) to identify clients where all three risk signals fire at once. When a device generates alerts, fails backups, and creates tickets simultaneously, it points to a systemic problem rather than isolated incidents.
This report crosses Datto RMM alert data (135,387 alerts), N-able backup statistics (169 active devices, 92.9% success rate), and Autotask ticket data (67,521 tickets) to identify clients where all three risk signals fire at once. When a device generates alerts, fails backups, and creates tickets simultaneously, it points to a systemic problem rather than isolated incidents.
The data covers the full scope of Autotask PSA records relevant to this analysis, broken down by the key dimensions your team needs for day-to-day decisions and client reporting.
Who should use this: NOC teams, asset managers, and service delivery leads
How often: Weekly for fleet reviews, monthly for lifecycle planning, quarterly for budgeting
This report crosses Datto RMM alert data (135,387 alerts), N-able backup statistics (169 active devices, 92.9% success rate), and Autotask ticket data (67,521 tickets) to identify clients where all three risk signals fire at once. When a device generates alerts, fails backups, and creates tickets simultaneously, it points to a systemic problem rather than isolated incidents.
Client A alone accounts for 19.8% of all alerts (26,873 out of 135,387). The top three clients generate 32.2% of total alert volume. This level of concentration means a targeted cleanup of monitoring policies on just 3 accounts could cut overall alert noise by a third.
EVALUATE ROW("TotalAlerts", COUNTROWS('BI_Datto_Rmm_Alerts'), "ResolvedAlerts", COUNTAX(FILTER('BI_Datto_Rmm_Alerts', 'BI_Datto_Rmm_Alerts'[resolved] = TRUE()), 1), "BackupServices", SUM('BI_Backup_SaasProtection_Backup_Stats'[active_services_count]), "BackupWithRecent", SUM('BI_Backup_SaasProtection_Backup_Stats'[active_services_with_recent_backup_count]), "TotalTickets", [Tickets - Count - Created], "RebootRequired", COUNTAX(FILTER('BI_Datto_Rmm_Devices', 'BI_Datto_Rmm_Devices'[Reboot_Required] = TRUE()), 1))| Client | Alerts | Backup Rate | Tickets |
|---|---|---|---|
| Client A | 26,873 | No data | 2,775 |
| Client B | 9,307 | No data | 5,458 |
| Client C | 7,430 | No data | 1,803 |
| Client D | 5,032 | No data | 2,376 |
| Client E | 4,086 | No data | 2,180 |
| Client F | 3,838 | 100% | 5,290 |
| Client G | 3,437 | 100% | 1,758 |
| Client H | 2,646 | No data | 1,002 |
| Client I | 2,920 | No data | 682 |
| Client J | 2,033 | 100% | 6,381 |
Client J is the standout triple-risk case: 2,033 alerts and 6,381 tickets despite a 100% backup success rate. This means the alert-to-ticket pipeline is running hot regardless of backup health. Client B follows closely with 9,307 alerts and 5,458 tickets but no backup data at all, which means there is no safety net if those alerts escalate to data loss.
Seven of the ten triple-risk clients have no backup data linked. That does not necessarily mean they lack backups. It means the N-able backup agent is either not deployed or not mapped to the same company record in the data model. Either way, it is a blind spot.
EVALUATE
TOPN(10,
FILTER(
SUMMARIZECOLUMNS(
BI_Autotask_Companies[company_name],
"Alerts", COUNTROWS(BI_Datto_Rmm_Alerts),
"BackupRate", [NAble - Backup Success Rate %],
"Tickets", [Tickets - Count - Created]
),
[Alerts] > 100 && [Tickets] > 50
),
[Alerts], DESC
)Only 3 of the top 10 triple-risk clients have N-able backup data linked to their company record. The 3 that do have it (Client F, Client G, Client J) all show 100% backup success, which is a good sign. But 70% of the highest-risk clients are operating without any backup visibility in the data model.
This does not prove those 7 clients lack backup protection. They may use a different backup product, or their N-able agent data may be mapped under a different company name. The action item is straightforward: verify backup coverage for those 7 clients and either deploy N-able or fix the mapping.
| Client | First Response Met | Overdue Tickets | Risk Level |
|---|---|---|---|
| Client J | 43.2% | 113 | Critical |
| Client B | 88.2% | 65 | Critical |
| Client K | 87.5% | 40 | High |
| Client L | 70.1% | 36 | High |
| Client M | 73.7% | 33 | High |
| Client E | 84.9% | 25 | High |
| Client D | 86.0% | 20 | Medium |
| Client C | 75.4% | 20 | Medium |
Client J stands out again: just 43.2% first response SLA met and 113 overdue tickets. Combined with 2,033 alerts and 6,381 total tickets from Section 3.0, this client is absorbing a disproportionate share of service desk capacity while missing SLA targets on more than half of their tickets.
Client L and Client M both sit below 75% first response rate. These are not triple-risk clients from the alert/backup/ticket analysis, but their SLA numbers suggest they would benefit from the same root cause investigation: are the overdue tickets driven by alert noise that floods the queue?
EVALUATE TOPN(10,
SUMMARIZECOLUMNS(
BI_Autotask_Companies[company_name],
"FirstResponseMet", [Tickets - First Response Met %],
"Overdue", [Tickets - Overdue]
),
[Tickets - Overdue], DESC
)A 9% alert-to-ticket conversion rate tells two stories at once. On one hand, it shows that monitoring policies are set up broadly, catching low-severity events that resolve on their own. On the other hand, it means 91% of alerts never become actionable work, creating noise that desensitizes the team to real problems.
The ratio between total tickets (67,521) and alert tickets (12,208) means roughly 18% of all tickets originate from RMM alerts. The remaining 82% come from other channels: user reports, scheduled tasks, and proactive work. This is a healthy split. The concern is not the volume of alert tickets, but whether the right alerts are creating tickets and the wrong ones are being suppressed.
2,033 alerts, 6,381 tickets, 113 overdue, and a 43.2% first response SLA rate. Despite having 100% backup success, the alert and ticket volume is overwhelming the service desk. This client needs an immediate review of monitoring policies and ticket routing rules.
Seven of the top 10 triple-risk clients show no N-able backup data in the data model. This is either a deployment gap (no backup agent installed) or a mapping gap (agent data under a different company name). Either way, these are the clients most likely to experience data loss when alerts escalate, and there is no way to verify their backup health from the current data.
The top 3 clients generate 32.2% of all RMM alerts (43,610 of 135,387). When these alerts convert to tickets, even at a 9% rate, they add roughly 3,925 tickets to the queue. Tuning monitoring thresholds for just these 3 accounts would significantly reduce queue pressure across the board.
92.9% backup success across 169 active devices, with the three triple-risk clients that have backup data all showing 100% success. The backup infrastructure itself is working. The gap is in coverage and visibility, not in backup performance.
1. Run a monitoring policy audit for Client J, Client A, and Client B. These three clients account for the bulk of alert-to-ticket volume. Review which alert types are generating tickets and suppress or auto-resolve the ones that do not need human intervention. Start with disk space and CPU threshold alerts, which are the most common sources of noise.
2. Close the backup visibility gap for the 7 triple-risk clients without N-able data. For each one, verify whether N-able backup is deployed. If it is, fix the company name mapping in the data model so the backup data links to the correct Autotask company. If it is not deployed, that is a separate conversation about backup coverage requirements.
3. Prioritize Client J for SLA recovery. At 43.2% first response met and 113 overdue tickets, this client is in SLA breach territory. The root cause is likely the combination of high ticket volume (6,381) and alert-generated tickets crowding out tickets that need faster response times. Consider creating a dedicated queue or adjusting ticket priorities for alert-generated tickets.
4. Build a recurring triple-risk scorecard. The DAX queries in this report can run on a schedule. A monthly scorecard that flags clients with 100+ alerts, backup issues, and 50+ tickets would catch emerging risk patterns before they hit SLA performance. Track the trend over time to see whether policy changes actually reduce triple-risk counts.
A triple-risk client has all three risk signals active: more than 100 RMM alerts, more than 50 service tickets, and either backup failures or no backup data linked in the data model. The thresholds are set to filter out low-volume clients and focus on the accounts that generate the most operational load.
Backup data comes from N-able (BI_NAble_Device_Statistic) and connects to clients through company name matching. If a client uses a different backup product, or if the N-able agent data is stored under a different company name than the Autotask record, the backup column shows blank. It does not mean the client has no backups. It means there is no backup data linked to this specific company record.
The conversion rate divides the [Tickets - From Datto RMM Alerts] measure (12,208) by the total alert count (135,387). This gives 9.0%. The measure counts Autotask tickets that were created directly from a Datto RMM alert escalation, not tickets that happen to mention alerts in their description.
The [NAble - Backup Success Rate %] measure calculates the percentage of tracked devices with a recent successful backup. It uses data from BI_NAble_Device_Statistic and covers 169 active devices. A 92.9% rate means roughly 157 devices have recent successful backups, while 12 have missed or failed their latest backup job.
Start with the backup visibility gap (recommendation 2). Knowing whether 7 triple-risk clients have backup protection is more urgent than tuning alert policies. Next, address Client J's SLA situation (recommendation 3) because 113 overdue tickets affects client retention. Then tackle the monitoring policy audit (recommendation 1). The recurring scorecard (recommendation 4) can wait until the first three actions are underway.
Yes. All four DAX queries used in this report are production-ready and can be executed via the Power BI MCP server on a schedule. A monthly run would track whether triple-risk client counts decrease after policy changes, whether backup coverage gaps close, and whether SLA performance improves for the flagged accounts.
Connect Proxuma Power BI to your PSA, RMM, and M365 environment, use an MCP-compatible AI to ask questions, and generate custom reports - in minutes, not days.
See more reports Get started