Reading Infohub Logs

The three destinations#

Pick by the kind of problem:

• Nothing is running at all → the Windows event log.
• Things are running but a measure is wrong → the in-database engine log.
• A script failed → its CLI log file.

Going to the wrong one first is the most common reason a diagnosis takes longer than it should.

The Windows event log#

Infohub creates a custom event log named Flow, with an event source named Flow Bootstrap. It is not in the Application log — look for Flow in the list of logs in Event Viewer.

This is where to look when Infohub is not running:

• The Flow Bootstrap service failing to start
• Licence refusals — a component that will not run because the instance is not licensed
• A Platform that cannot be claimed
• Fatal hosting errors

The in-database engine log#

The engine writes operational detail into the Infohub database, per engine, and this is where the substance of most troubleshooting is. Each entry carries:

The four levels#

Warnings deserve more attention than they usually get. A warning repeating every pass is a real problem being tolerated: a source returning nothing, a value being discarded, a condition being worked around. Errors get investigated because they are loud; warnings accumulate quietly for months.

How to read it effectively#

Filter by time first. Establish when the problem started — the period a measure stopped at, the date a value went wrong — and look at that window. Reading a log from the beginning is hopeless.

Filter by level. Errors first, then warnings around the same time.

Look for repetition. The same error every pass is the single clearest signal available. A measure stuck at a specific period with a repeating error for that period is a retry loop, and the error text names the cause.

Read the whole message. Infohub's messages generally name the entity, the period, and the underlying exception. The detail is often the answer rather than a hint towards it.

Correlate across levels. An error in retrieval followed by warnings in aggregation is one problem with a downstream symptom, not two problems. Fix the lowest one.

Diagnostic logging#

Engines carry a Diagnostic property that enables detailed logging.

Use it deliberately:

1. Turn it on for the engine concerned.
2. Reproduce the problem, or wait for a pass or two.
3. Read the output.
4. Turn it off.

It produces a great deal of output, and leaving it on in steady state grows the log and adds work for no benefit. It is an investigation tool, not a setting.

CLI log files#

--logfile <path> writes a log of a CLI run. In automated runs, use it on every step and keep the logs as build artefacts — when a run fails at step 340, that log is the evidence.

Two things worth knowing about 7.2.0:

The log is now reliably written. Parse errors, edition-gated verbs, and --help all produce a log file. Earlier builds did not create one in those cases, so a script targeting an older Infohub may find nothing after a failure — do not machine-parse logs on older builds.

Progress indicators become static when output is redirected, so a captured log is readable rather than full of spinner characters.

Log growth#

The in-database log grows, and on a busy instance with diagnostic logging left on it can grow substantially.

Include it in your view of database growth, and treat an unexpectedly large log as a signal: either diagnostic logging was left enabled, or something is generating a high rate of warnings that nobody is reading. Both are worth acting on.

Correlating with what changed#

For "it stopped and nothing changed", the log tells you when, and the when usually identifies the cause.

Note the exact timestamp of the first failure and ask what happened around it:

• A credential rotation or password change
• A certificate expiry
• A source system upgrade or restart
• A server rename, or a database restored elsewhere
• An Infohub deployment
• A network or firewall change
• A licence or maintenance date passing

The log rarely says "the certificate expired". It says the connection failed at 03:14 on a particular date, and the date is what makes somebody remember the change.

What the logs will not tell you#

Worth knowing so you do not search for what is not there.

A value that is plausible but wrong. An aggregation type mistake, a wrong unit, an unguarded division that returns zero rather than failing — these produce no log entry because nothing failed. They need the diagnostic reasoning rather than a log search.

Deployment state. Whether an object is Different — running the old configuration — is not an error and is not logged as one. Check --deployment-status.

Whether anyone is reading a dashboard. Usage is not what these logs are for.

A practical sequence#

When something is wrong:

1. Is anything running? No → Windows event log, source Flow Bootstrap.
2. Something specific is wrong? → in-database engine log, filtered to when it started.
3. Look for repeats — a repeating error is the answer most of the time.
4. Read warnings too, around the same window.
5. Still unclear? Enable Diagnostic on that engine, reproduce, read, disable.
6. Nothing failed but the number is wrong? The logs will not help — reason about the model instead.

Before you escalate#

Include, with timestamps:

1. Which log the entries came from.
2. The exact time the problem started.
3. The full text of the first error, not a summary.
4. Whether it repeats, and how often.
5. Any warnings around the same time.
6. What changed around that date.
7. The deployment state of the objects involved.

See also#

• Diagnosing Missing Data
• Diagnosing Stuck or Faulted Measures
• Running the Data Engine
• Exit Codes and Error Handling