Your config backups are failing and the dashboard says everything is fine

Here is a quietly alarming post from the SolarWinds community. An experienced admin discovered that NCM config downloads in his environment were failing with ACCESS-DENIED errors, and the failures never showed up in the UI. No red status. No failed-job indicator. The backups simply were not happening, invisibly, and he notes he has "seen this catch out a lot of environments," discovered "weeks later."

His fix was to write a custom SQL alert directly against the database to surface the hidden failures, and to publish it so other admins could do the same. Good community work. Also a damning requirement: the product's account of its own collection health needed an unofficial database query to be trustworthy.

Why silent failure is the worst failure

An alert storm is annoying. A monitoring gap you know about is manageable. A gap the tool actively reports as healthy is the dangerous case, because everything downstream of it inherits false confidence.

Config backups make the point sharply. Nobody looks at config backups on a normal day. They exist for the abnormal day: a bricked switch after a bad change, an audit request, a compliance report, a 2 a.m. restore. The failure mode of a silently broken backup job is that you discover it at exactly the moment you needed it to have worked, with weeks or months of missing history behind it. It is the operational equivalent of a fire extinguisher that reads full and is empty.

The same logic applies across a monitoring estate. A poller that stopped collecting from a subnet. A credential that expired against fifty devices. An SNMP agent that went quiet after a firmware update. In each case the difference between "no data" and "everything is fine" is the difference between a tool you can trust and a tool you have to audit.

Collection failure is a first-class alert

The principle that falls out of this is simple to state and rarely implemented: a monitoring platform must monitor itself, and collection failure must be a first-class alert, not a log line.

Concretely, that means job-level accounting for every scheduled collection: config backups, hardware polls, discovery runs, each with an explicit succeeded, failed, or skipped status that rolls up somewhere a human looks. It means credential health as a monitored object, because expired or mis-scoped credentials are the leading cause of quiet gaps. It means data-freshness checks: not "is the device up" but "when did we last successfully collect from it, and is that recent enough." And it means an evidence trail, so that when an auditor asks whether you can prove config coverage for the quarter, the answer is a report, not an archaeology project.

If your current platform cannot answer "which of my scheduled collections failed this week" in one view, you do not have a monitoring problem. You have a monitoring-of-monitoring problem, and it is being solved today by individual admins writing SQL against vendor databases.

Asset truth depends on it

There is a bigger reason to care. Configuration archives, hardware inventory, and asset records are only as good as the collection pipeline that feeds them. A CMDB fed by a silently failing collector is not slightly wrong; it is confidently wrong, which is worse. Change tracking, drift detection, warranty management, capacity planning, every downstream discipline assumes the collection layer is honest about itself. That assumption should be enforced by the product, not by the customer's initiative.

Where Sensaka fits

Sensaka treats collection health as part of the product, not an admin project. Scheduled jobs carry explicit success and failure states, collection gaps surface as alerts, and configuration and asset data carry the evidence trail that audits and root-cause work depend on. The design goal is blunt: the platform should never claim health it cannot prove.

If you have ever discovered a monitoring gap weeks after it opened, you already know why this matters. We are happy to show you what honest collection accounting looks like on your own devices.

Further reading: explore SolarWinds Alternatives, Multi-Vendor Hardware Monitoring, Sensaka DCOS, and Redfish & IPMI Reference.