When the dashboard says 0% and everything is up

A ManageEngine customer posted a question about Analytics Plus that deserves more attention than its single thread received. His reports, fed from Applications Manager, showed 0% availability for the day across a list of business applications. Not obscure ones: the call centre, claims management, creditors payment, Exchange, SharePoint, SAP reporting, messaging. All flatlined to zero, all actually running. His question to the community: any clues?

Anyone who has operated monitoring at scale recognizes the moment. Somewhere between the collector, the integration, and the reporting layer, the data pipeline broke, and instead of saying "no data," the dashboard confidently reported the worst possible number. A wall of red for systems in perfect health.

The same community's support forums record the mirror image: ManageEngine's self-service password tool reportedly showing users a missing sign-in icon while the underlying function still worked. Right state, wrong signal, in the opposite direction. Between them, the two reports frame the actual subject: the fidelity of the signal layer itself.

False data is worse than no data

A gap in monitoring is a known unknown; teams route around it. False data is an unknown unknown wearing a confident face, and it does damage in both directions.

False red, like the 0% wall, triggers investigation of healthy systems, and then, far more corrosively, teaches the team the lesson they will never unlearn: the dashboard cries wolf. The next wall of red gets a shrug. Alert fatigue is usually blamed on volume, but its deeper cause is credibility; one confidently wrong report discounts every future report.

False green is quieter and worse: a gap dressed as health, discovered only when the thing it hid becomes an incident. Either way, the moment a team starts double-checking the monitoring tool against reality by hand, the tool has lost its reason to exist. Monitoring is a trust product. It has no other function than to be believed.

Distinguish "zero" from "unknown," structurally

The engineering principle underneath is small and non-negotiable: a monitoring pipeline must represent the absence of data as absence, never as a value. "Availability 0%" and "availability unknown, collection failed" are entirely different statements, and any layer that collapses the second into the first, a collector timing out, an integration silently dropping records, a report defaulting nulls to zero, is manufacturing false incidents.

That principle turns into checkable product behavior. Data freshness should be visible next to every number: this figure is based on collection as of when. Pipeline health should be monitored like a first-class system, with the integration between collector and reporting layer alerting on its own failures rather than passing zeros downstream. And a wrong wall of red should be explainable: from any suspicious number, an operator should be able to trace to the underlying collection events and see where the pipeline broke, without a support ticket.

During any evaluation, test this deliberately. Break the collection path on purpose, block a credential, stop a collector, and watch what the dashboards say. The products worth trusting say "unknown, since 09:14, here's why." The ones to avoid say 0%, or worse, 100%.

Where Sensaka fits

Sensaka is built on the trust principle: collection failures surface as collection failures, freshness is visible, and no layer of the platform converts "we don't know" into a number. We hold that line because everything else we do, hardware health, asset truth, alerting, is downstream of whether an operator can believe the screen.

Run the break-it test on us during a trial. We designed for it, and a vendor who flinches at that test has answered your real question.

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