Monitoring & Alerting
65 monitor types across web, network, mail, databases, storage, infrastructure and cloud, plus any Nagios plugin, with incidents that manage themselves.
Your monitors at a glance
Watch everything that matters
Web / HTTP
HTTP and HTTPS availability, status codes, keyword matching, JSON checks, header checks, response time and SSL certificate expiry.
Network
Ping, TCP ports, DNS and DNS-record checks, DNS blocklists, NTP, SNMP and domain-expiry monitoring.
SMTP, IMAP and POP3, with or without implicit TLS.
Infrastructure
SSH, SFTP, RDP, SMB, LDAP and LDAPS, PostgreSQL, MySQL, SQL Server, MongoDB and Redis.
Cloud
AWS CloudWatch alarms, EC2 and RDS instances. Azure resource health and Azure Monitor metrics. Microsoft 365 service health.
Heartbeats
Push-style monitors that alert when a scheduled job or system stops checking in.
Nagios plugins
Already rely on Nagios checks? Install the standard plugins, or your own, next to the site collector and run them by name. OK, WARNING and CRITICAL map onto TechSavve’s alerts, and the performance data each plugin prints is graphed.
Virtual machines
VMware host and VM status checks, and whole vCenter, ESXi, Hyper-V, Proxmox and KVM estates read in one go. See Virtualization & Cloud.
Your own Prometheus and Grafana New
Already run them? Keep them. Connect an existing Prometheus or Grafana, self-hosted or on AWS, and see its machines, alerts and dashboards here. Optional and off until you turn it on; neither one is installed with TechSavve RMM.
Checks for the rest of the stack New
Beyond the usual web, network and mail checks, the site collector can ask your storage, power, network and container systems how they are doing, with read-only credentials kept in an encrypted vault.
Storage and backup
Synology DSM, QNAP, TrueNAS, Veeam Backup & Replication and Acronis Cyber Protect Cloud: pool and disk health, capacity, backup and replication jobs, and the alerts each system raises itself.
Power and hardware
UPS units over SNMP (APC, CyberPower and Eaton are recognized by name), printers (supplies and error states), and the iDRAC, iLO or other Redfish controller in a server: drives, fans, temperatures, power and firmware.
Network and VPN
UniFi controllers, Tailscale (key expiry, approvals, unapproved routes), RADIUS and LDAP or Active Directory bind checks, plus firewall rule audits for FortiGate, pfSense and Cisco ASA.
Containers and applications
Kubernetes clusters, WordPress and other application versions, REST API checks, SQL queries and SSH commands whose expected results you define.
New. These checks were built against vendor documentation and tested with recorded and simulated answers. Tell us which systems you run and we will confirm them against your environment before you commit.
From failure to incident, automatically
A single failed check is noise. TechSavve waits for consecutive failures past a threshold you control before it opens one incident and one alert, so your team is not buried in duplicates.
- Alerts are de-duplicated and escalated by severity
- Incidents automatically create a ticket
- Recovery resolves the alert and closes the incident
- Devices that miss their check-in window are marked stale
Device health, from the collector
Resource thresholds
CPU, memory, system and data disks (each with its own limits), ping latency, packet loss, bandwidth, disk I/O latency, CPU temperature and power-supply status where the hardware reports them. Every one has warning and critical levels and a sustained-duration window, so a brief spike does not page anyone.
Fewer, smarter alerts
When a device goes down, its other sensor alerts are acknowledged automatically, so one outage is one incident instead of forty. They are checked again the moment the device returns.
The platform watches itself
Collectors that go quiet and devices that start failing together are noticed and explained, not left as a pile of unrelated alerts.
Watched Windows services
Choose the services that matter on a Windows device and how serious it is when one stops. A stopped service raises an alert, and auto-remediation can run your approved script to start it again.
Unreachable, not down
Tell TechSavve which switch, firewall or host a device is reached through. While that parent is down, the devices behind it show as Unreachable and open no incidents of their own, so one dead switch is one page. Virtual machines are linked to their hosts automatically.
Quieter alerts, in one click New
Most monitoring noise is the same few things: a brief spike, a nightly backup, a device that is simply busy at nine in the morning. TechSavve looks at your own alert history and suggests the fix.
Wait before alerting
Raise the alert only if the condition lasts a number of minutes you choose.
Raise the warning level
Move a threshold for one device, one monitor or a whole customer.
Mute known windows
Stay quiet during backups or other planned work, using the same maintenance windows as everything else.
Learn what is normal
Judge a device against its own pattern for that hour of the week, once it has enough history.
Every alert has a Tune this button, and the Tune alerts page lists suggestions with how many alerts each would have avoided. The Alert Noise report shows the same list. Nothing changes until you apply a suggestion, and tuned alerts still open incidents when they really last.
Predicted issues: early warnings, before anything breaks
TechSavve works out what is heading for trouble from the readings, logs and backup status it already collects. Each warning shows its evidence on a chart, says how sure it is, and can be rated or snoozed. They are advice, never alarms: nothing pages anyone and no ticket opens by itself. You choose how long raw readings, daily summaries and status history are kept.
Disk filling up
A disk that will be full in about three weeks, worked out from its trend, with cleanups and one-off jumps not mistaken for a trend.
Memory climbing
Memory that keeps growing without coming back down, the signature of a leak.
Restarts and drop-outs
A device that restarts on its own, or keeps dropping out and coming back.
Devices failing together
Several devices starting to fail at once, which usually points at the network or the collector, not the devices themselves.
Unusual for this time
Readings that are out of character for that device at that time of day, judged against its own history.
Sign-in guessing
Failed sign-ins arriving from the internet, and a sign-in that succeeds right after guessing. See Security.
Disks and RAID
A disk reporting pending or reallocated sectors, heavy wear or a high temperature, and a RAID array that has lost a member, read from each disk’s own health report on Windows, Linux and Synology devices. A device that cannot report says Not reported, never healthy.
Telltale log entries
Counts, never message text: out-of-memory kills, disk and hardware errors, restarts without a clean shutdown, and a source that has started reporting errors it never did before. Read from the Windows event logs and the Linux system journal, with known noise such as failed Store-app updates left out.
Backups that stopped
A backup that has not run when it should, or whose last run failed. TechSavve reads Synology Hyper Backup status directly and watches any other job that checks in with a heartbeat. A machine that only syncs to the cloud is labelled that way, not as backed up.
One problem, one incident
When a network change, a bad update or a failing link takes down many devices at once, you should get one page about the cause, not eight about the symptoms.
One cause, one incident
When several devices behind one collector fail the same way at the same time, TechSavve opens one incident, one ticket and one page for the shared cause instead of one each. The devices stay listed on it, and everything closes together when the cause clears.
A single device is still its own incident
A device that fails alone, or in a way the others do not, gets its own incident exactly as before. Grouping needs at least three devices, and at least half of that collector’s devices, failing the same way. It can be switched off.
Starts from the cause
The incident names the error the devices share and shows when each one started failing, so a technician begins with the cause rather than the symptoms.
Many failures, a few situations New
When twelve devices go quiet, the dashboard should say what it thinks is happening and how sure it is, not list twelve rows.
Situations, not rows
An Incident correlation card on the dashboard groups what is failing: a device that cannot be reached because the one it sits behind is down, a collector with a recorded problem (with roll-back advice if it was just updated), a site where at least three watched devices and half of them are down with nothing else to explain it, and incidents that follow a recorded change.
Says how sure it is
Every situation lists what it was concluded from. A recorded dependency or a collector problem reads “likely”. A whole-site outage is inferred from the pattern, is marked “needs verification”, and names the network device among the failures so it is checked first.
A next step, never an action
Each one ends with something to check. Nothing runs by itself because of this card, and it is worked out by rules, not by AI. For your technicians; customers do not see it.
Fixes counted, time estimated
Automatic fixes counts the runbook runs that fixed a problem and the alerts that cleared after an automatic fix in the last 24 hours. Technician time saved is an estimate of 15 minutes per fix, and the tile says so.
New. Verified with automated tests and on a test database. The conclusions are inferences from patterns the platform can see, which is why each one shows its basis and asks to be verified. With an AI engine set up, each situation also has an optional Explain with AI button.
What changed before it broke New
Most outages start with something that changed. TechSavve now keeps that record and puts it next to the problem, with the likeliest cause first.
A timeline beside every problem
On an alert, an incident, a ticket and a device, a timeline shows what changed in the day before it began: updates installed, scripts run, configuration changes, restarts, collector updates, administrator actions, maintenance and automatic fixes, DNS changes, and other alerts around the same time.
Down to the device
Programs installed, removed or updated, operating system builds, services stopped or changed, new network addresses and gateways, and disks added are recorded as they happen. A scan every six hours adds updates installed outside TechSavve, local administrators, firewall rules and scheduled tasks on Windows, Linux and macOS devices, by name only. It can be switched off for the platform or for one device.
The likeliest cause first
Changes are ranked by how well they fit the kind of problem, how close in time they were and whether they hit the device or only its site. It says “Likely cause” only when one change stands clearly ahead, otherwise “Possible causes”, never certainty. Planned changes are labelled planned, and it says which sources were and were not recorded for that device.
Where you already look
The top cause shows under the alert, in the email, text and phone notification, as an automatic internal note on the ticket, and in the facts the AI assistant explains from. Script output is never shown.
Technicians teach it
Mark a change as the cause or not the cause. A confirmed cause moves to the top; a ruled-out one drops off the list but stays on the timeline. Once enough answers have come in they also adjust the ranking.
Roll back, and show the customer
When the change was to a device’s saved configuration, an administrator can roll it back from the timeline if the earlier version is on file. The quarterly business review lists what was behind the incidents, and the customer portal can show each customer their recent incidents with the cause in plain words, only when a likely or confirmed one was found.
New. Verified with automated tests, on a test database and on our own NOC. It can only show changes from the time recording began: a device’s first reading is a starting point, and a removed disk or anything before recording started is not shown. A ranking is not a diagnosis, so it is worded as a likelihood.
Updates that watch themselves
A collector update that breaks monitoring is worse than no update. TechSavve treats every update as something to be checked.
Checked, then put back if needed
For the first hour after a collector updates itself, TechSavve compares how its devices were collected before and after. If collection gets worse, the previous version is put back automatically, that version is held so it is not offered again, and every administrator is emailed what happened. A collector also puts its own previous build back if the new one cannot complete a cycle.
Try it on a few first
Mark some collectors as canaries. A new version goes to them first, and to the rest only after the canaries have run it for a day and been judged healthy. You can also hold a version before it goes anywhere.
Quiet while it is checked
While an update is being checked, devices that start failing together do not open incidents or tickets. If the update is put back and they recover, nothing was ever opened.
Laptops that leave the network New
A collector can only reach what is on the site network. For laptops that spend their days at home or on the road there is an optional check-in helper: a small script that runs as a scheduled task or timer and reports over HTTPS every few minutes.
Read-only
It reports facts and takes no commands. There is no program to sign or update, and a customer can read the script before it runs.
Enrolled with a site token
Each site has its own enrollment token, and the key a device receives is stored only as a hash on the server.
Off the network is not down
A laptop that checks in shows as Off the office network instead of raising a down alert, and its status keeps counting from the last check-in.
Carries the compliance checks
The same read-only posture checks used by compliance packs can run through the helper, so a laptop at home is still measured.
New. The Windows and Linux helpers are tested. The macOS helper is new and has not yet been run on real Macs.
Maintenance windows
Planned work should not page anyone. Schedule a window once or weekly for a whole customer or any mix of sites, devices and monitors. While it is open, new alerts for what it covers are recorded but acknowledged by the system, so no incident, ticket or page opens. When it ends, anything still wrong comes back on its own.
Start one in a click
Technicians can start a short window from a device page, or on many devices at once from the Devices list.
Nothing is hidden
Alerts and devices show an In maintenance badge, monitoring carries on, and an incident that was already open is never touched.
Patching plays along
A patch run that may restart a device opens its own window, so the restart does not page anyone.
Graphs for everything you measure
Performance Graphs
Every reading TechSavve collects, charted: CPU, memory, disks, latency, traffic and temperature for devices, response times for monitors, and the performance data Nagios plugins print. Pick any period from the last four hours to the last 30 days.
Graph Explorer
Put several hosts on one chart to compare them, see which alerts fire most often, and see how long each host and service was down or out of touch.
Business services, not just boxes
Your customers do not care that a server is down. They care that email or the website is. Describe each service and what it depends on, and TechSavve tells you how the service itself is doing.
Up, degraded or down
A service’s state comes from the devices and monitors it depends on. Redundancy is understood: two web servers out of three still means the website is up, just degraded.
Its own history
Every service keeps its own availability history, so you can show a customer how their email did this month, not how a server did.
Alert on the service
Optionally open an incident when a service goes down or degraded, through the same tickets, on-call and maintenance windows as everything else. One board shows the services of every customer.
Related guides
Agentless vs agent-based RMM: how they differ and when each fits
How agent-based and agentless RMM monitoring work, where each is stronger, the security trade-offs, and how to choose for your customers.
How to stop customer SSL certificates expiring by surprise
Why certificates still expire with auto-renewal, the shorter lifetimes coming, and a routine that catches every certificate before it runs out.
See TechSavve RMM in action
Book a free demo with the DFWTechPros team.