Diagnosing Missing Data
A procedure that finds the cause quickly — work down the chain from the measure to the source, in order.
"There is no data" is the most common Infohub support question, and it has perhaps a dozen causes. Working through them in a fixed order finds the answer far faster than guessing, because each step rules out a whole class of problem.
Establish the shape of the problem first#
Before investigating anything, answer three questions. They determine which branch to follow.
1. How much is missing?
| Scope | Look at |
|---|---|
| One measure | That measure's configuration |
| All measures on one connection | The connection |
| All measures in one area | Engine assignment for that area |
| Everything | Bootstrap, the Platform, or the database |
| One period, everything else fine | The source, or a freeze point |
2. Was it ever working? Never working is a configuration problem. Stopped working is an environmental change — a credential, a certificate, a network route, a server rename.
3. Which measure in the chain? Walk down from the measure that is missing to its source. If the daily is empty, check the hourly; if the hourly is empty, check the tag measure. Find the lowest measure in the chain that has no data — that is where the problem is. Everything above it is a symptom.
That third step alone resolves a large proportion of cases, because people usually report the top of the chain.
The procedure#
Work down. Stop when you find the cause.
1. Is it deployed?#
The single most common cause. Saving configuration does not activate it.
Check the deployment state of the connection, the engine, and the server. Not Deployed and Undeployed are obvious. Different is the one that catches people: the object is running the old configuration, so your change has no effect, and nothing reports an error.
--deployment-status
2. Does the Platform host name match?#
Flow Bootstrap claims the Platform whose host name matches the machine it runs on. A Platform naming a different machine never starts anything.
This bites after a database restore onto another server, a server rename, or a model built elsewhere. If nothing at all is running and the configuration looks perfect, this is almost always it.
3. Is Flow Bootstrap running?#
Check the Services list on the Platform host. If it will not start, read the Flow event log.
4. Is the content assigned to an engine?#
Metrics, time schemes, and event schemes each belong to an engine. Anything unassigned is never processed — it looks correct and produces nothing.
This is the usual cause when one area of a model is silent while everything else works.
5. Can the connection reach the source, right now?#
Browse the connection's tag namespace. That single action proves the network path, the credentials, and the source being up.
If browsing fails, the problem is the connection, and the data source articles cover the specifics per connector.
6. Does the tag exist, exactly?#
Compare the measure's tag against the browsed namespace, character for character. Trailing spaces and case differences are common and invisible.
For templated measures, check the resolved tag — a model attribute formatted as 10 instead of 010 produces a tag that does not exist, on some instances only.
7. Does the source have data for that period?#
Query the source system directly for the same window. If the source is empty, Infohub is behaving correctly and the problem is upstream.
This step is worth doing early when the report is "a gap yesterday" rather than "nothing ever".
8. Would the service account have the same access?#
A connection tested in Flow Config runs as you. Deployed, it runs as the Flow Bootstrap service account.
For anything using Windows integrated security — OPC, several historians, SQL trusted connections, a network file share — this difference is the most common cause of "works in Config, fails deployed".
9. Is it an overlap problem on a slow tag?#
If a measure has values during active periods and nothing overnight or at weekends, the tag has simply not changed, and the query window does not reach back to the last value.
Increase Backward Overlap on the measure. This is a genuine gap in a great many models and is easily mistaken for a source outage.
10. Is the freeze point discarding it?#
If recent values arrive but older periods never update, the time scheme's freeze point marks them closed. Move it back, recalculate, move it forward.
11. Is the calculation failing?#
For a calculated measure with no values, the expression is failing every interval. The most common causes are an unguarded division and a null reference.
Gaps only on weekends, shutdowns, or month boundaries are the signature of an unguarded division meeting a zero denominator. See The Zero Guard.
12. What does the log say?#
The Flow event log records connector errors, calculation failures, and engine problems. See Reading Infohub Logs.
Leaving this to step 12 is deliberate: the earlier steps are faster and resolve most cases. But when they have not, the log is where the answer is.
Common patterns#
Recognising these saves working the whole list.
| Pattern | Cause |
|---|---|
| Nothing anywhere, no errors | Platform host mismatch, or Bootstrap not running |
| One connection's measures all empty | Connection not deployed, or credentials |
| Change had no effect | Deployment state Different |
| One area silent | No engine assignment |
| Works in Config, fails deployed | Service account |
| Gaps overnight and at weekends on slow tags | Backward overlap |
| Gaps on shutdown days for ratios only | Unguarded division |
| Older periods frozen | Freeze point |
| Values stop at a specific date | Freeze point, licence expiry, or a manual time scheme out of periods |
| Stopped after months, nothing changed | A credential or certificate expired |
| Some templated instances only | Model attribute value formatting |
| Daily empty, hourly fine | Aggregation not configured, or not assigned to an engine |
| Tag measure has data, hourly does not | Aggregation misconfigured, or the chain is not contiguous |
When it stopped rather than never started#
Environmental change is the cause. In rough order of likelihood:
- A credential expired or was rotated — SQL password, API secret, OAuth client secret, server key.
- A certificate expired — OPC UA, TLS to a broker or API.
- A server was renamed or replaced — Platform host no longer matches.
- A source system was upgraded — client library version mismatch, changed API shape, new Canary version needing the other connector.
- A network route or firewall rule changed.
- A licence or maintenance date passed.
- Someone edited and did not deploy — state is Different.
Ask what changed around the date it stopped. The answer is usually in that list, and it is usually not something anyone thought would affect Infohub.
Before you escalate#
Have these ready — it turns a long conversation into a short one:
- Scope — one measure, one connection, one area, or everything.
- The lowest measure in the chain with no data, and its configuration.
- When it last worked, and what changed around then.
- Deployment state of the connection, engine, and server.
- Whether the namespace browses right now.
- Whether the source has data for the period, checked directly.
- Relevant
Flowevent log entries, with timestamps.
The prevention that pays for itself#
Most of this article becomes unnecessary with two habits.
Check deployment status routinely. Different and Faulted are both silent and both mean the model in the database is not the model that is running. A scheduled check catches them in minutes rather than weeks — see CLI Recipes for CI.
Record credential and certificate expiry dates. The single largest category of "it stopped and nothing changed" is something expiring on a date somebody could have known in advance.