Most aggregation functions describe the values in your data - how high, how low, how average. The count aggregate ignores the values entirely and answers a quieter but crucial question: how many samples were there? That number turns out to be one of the best early warnings a historian offers, because it reveals whether the data you are about to average is complete or full of holes. A count that comes back lower than expected means an average or a maximum computed over the same window is standing on missing ground.
Count Aggregate in one line: The count aggregate returns how many samples fell into each time window of a query, saying nothing about their values. Its value is as a completeness and collector-health check: comparing the actual count against the count you expected reveals data gaps, dropped connections, and dead tags before value-based aggregates silently report over incomplete data.
It is easy to conflate count with sum, but they measure completely different things. Sum adds up the sample values; count adds up the samples themselves. If a pressure tag logged ten readings in an hour, the count for that hour is ten regardless of whether those readings were near zero or near a thousand. Count is a measure of how much data you have, not of what the data says. That indifference to value is exactly why it is useful as a health metric rather than a process metric.
In a time-series query the count aggregate is applied per interval like any other aggregation function: group the samples into hourly or minute buckets and count how many landed in each. The result is a trend not of the process but of the data density over time. A tag that normally logs on a steady interval will show a flat, predictable count per bucket, and any deviation from that flat line is a signal that something about the data collection changed.
Many historians distinguish a raw count from a count of good values. Samples can carry a quality flag, and a reading marked bad - because the collector could not reach the device, or the value was out of range - should not be trusted the way a good one is. Counting only the good samples per bucket gives a cleaner picture of how much reliable data you actually have, separating windows that are genuinely full from windows that look full but are padded with flagged, untrustworthy values.
The count aggregate earns its keep by comparison. If you know a tag should log a sample every fifteen seconds, you know how many samples an hour should contain, and the count aggregate tells you how many it actually did. A count that matches expectation means the collection chain worked; a count well below it means samples went missing during that window. This turns an invisible problem - data that simply is not there - into a visible, queryable number.
Those shortfalls map to real failures. A collector that lost its connection to a device stops producing samples, so the count for that period drops toward zero. A cellular link that dropped out for twenty minutes shows up as a dip in the count for the affected buckets. A tag that has quietly gone dead - a failed sensor, a misconfigured point - reveals itself as a count that has fallen to nothing while neighboring tags keep counting normally. None of these announce themselves in the value data, but all of them show plainly in the count.
The reason this matters so much is that value-based aggregates do not complain about missing data; they just compute over whatever is present. An average over an hour that should have had 240 samples but actually had 6 is still a number, and it looks just as authoritative as an average over a full window. Without the count beside it, you have no way to know that average was built from a trickle of data. The count is the guardrail that tells you whether to trust the numbers next to it.
For a cloud SCADA platform pulling data from remote, intermittently connected sites, the count aggregate is a natural completeness check. Sites on cellular or satellite links drop out, RTUs reboot, and collectors stall, and every one of those events shows up as a shortfall in samples. In a system like Merobix, querying the count per interval across a fleet of tags surfaces exactly which sites and which points stopped reporting and when, turning scattered gaps into a clear coverage map.
This makes count a useful basis for data-quality alerting rather than just after-the-fact investigation. A rule that watches for a per-interval count falling below its expected value can flag a stalled collector or a dead link close to when it happens, instead of leaving the gap to be discovered weeks later when someone questions a report. Because the check is about presence rather than value, it works uniformly across pressure, flow, level, and status tags without needing to know anything about what any of them should read.
Count also protects the integrity of everything derived downstream. Daily reports, allocation figures, and compliance summaries are all built from aggregates over the historian, and every one of them is only as sound as the completeness of the data underneath. Running the count aggregate alongside those value aggregates lets a team confirm that a day's average or total rests on a full record, and to flag or exclude windows where too little data arrived. The count is what keeps a clean-looking summary from quietly hiding the fact that half its data was never there.
Count tallies how many samples fell in a window; sum adds up their values. Ten readings in an hour give a count of ten no matter what those readings were, while their sum depends entirely on the values. Count measures how much data you have, which makes it a completeness and health metric rather than a measure of what the process did.
It means samples that should have been logged are missing for that window. Common causes are a collector that lost its connection, a dropped cellular or satellite link, an RTU reboot, or a tag that has gone dead. Because the shortfall is invisible in the value data, comparing the actual count against the expected count is often the first sign that collection failed.
Value-based aggregates compute over whatever samples are present and never signal that data is missing. An average built from six samples in a window that should have had hundreds looks just as authoritative as a full one. Placing the count beside the average tells you whether the summary rests on a complete record or on a handful of readings that happened to survive.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.