An Empty Table Is Not an Answer

Open a report. It is empty. What do you now know? Almost nothing, and that is the problem. An empty table means either there was nothing to report, or the query failed, or the collector stopped last Tuesday, or the filter you forgot you set excludes everything. All four render identically. Experienced engineers handle this by not trusting empty screens. They go and check the collector. That is a reasonable habit and a terrible tax, because it means the tool has quietly moved verification work onto the person using it. So our empty states say which one it is. No findings in the window reads as a sentence, in green, stating that the check ran and returned nothing. A gap in collection reads as a gap in collection, and names the interface or the device. There is a sharper version of this that took us longer to learn. The interfaces most likely to be missing history are the busiest ones, because they are the ones where collection is hardest. So the absence of data correlates inversely with how much you needed it. A tool that shows a flat line there is not merely unhelpful, it is actively misleading. We also refuse to build a screen for something we are not collecting. If a subsystem is not deployed, there is no tab for it. An empty tab implies something is being watched. Nothing is.