Diagnosing Stuck or Faulted Measures

Establish which kind it is#

Three quite different situations get reported the same way. Distinguish them first.

Each has its own causes, below. Getting the classification right is most of the work.

Start with the Activity window#

Before reasoning about causes, watch what the engine is actually doing with the measure. Right-click the measure and choose Activity, and a window opens in the editor space showing its processing as it happens — the states the engine moves it through, with detail per step and a Detailed Trace option when the summary is not enough.

This answers the first question directly, and it is a question that is otherwise guesswork: is the engine touching this measure at all?

• Activity, and the measure advances — the engine is working; the problem is upstream, in what it is being given.
• Activity, but no progress — it is being processed and failing, or waiting on something. The states name which.
• No activity whatsoever — the engine is not considering this measure. That is a different problem entirely: it usually means the measure's metric is assigned to no Data Engine, or to one that is not deployed. See Running the Data Engine.

That last case is worth checking first precisely because it produces no error anywhere. A measure nothing is processing looks exactly like a measure that is processing and producing nothing.

Not advancing#

The measure has values up to a point and then stops, while its siblings continue.

Its source stopped. Walk down the chain. If the hourly stopped, check the tag measure. Find the lowest measure that stopped — the problem is there, and everything above it is a symptom. See Diagnosing Missing Data.

A backlog it cannot clear. If the engine is retrying a period that will not succeed, it may not progress past it. The signature is a measure frozen at a specific date, often with repeated entries in the log for that same period.

Its engine is not processing it. Metrics, time schemes, and event schemes are each assigned to an engine. Content with no assignment is never processed. If one metric is frozen and everything around it is fine, check its engine assignment.

A dependency that cannot be satisfied. A calculation whose dependency has no value for a period may not produce one, and if that dependency never arrives the calculation waits indefinitely.

The freeze point. Values before the freeze point are not reworked. A measure that appears frozen at an old date may simply be behind a freeze point that moved.

Advancing but stale#

New periods appear and the value never changes, while the inputs plainly do. This is nearly always one of two things.

A missing declared dependency. Infohub recalculates a measure when a declared dependency changes. If the expression reaches a value by a route Infohub does not know about, that route does not trigger recalculation — so the measure computes once and then looks stuck.

This is the single most common cause of a stale calculated measure. Check the dependency list against what the expression actually references.

A held or forward-filled value. Where a measure carries the last known value forward — by design, through overlap, or through an expression that falls back to a previous period — a stale input produces a stale output that looks plausible. A ?? Measure_<id>[-1].Value fallback will hold a value indefinitely if the current one never arrives.

That pattern is defensible for slow-moving reference values and dangerous for anything operational, because nothing announces that the value is being held rather than measured.

Faulted#

Something is failing rather than merely absent.

Read the Flow event log. A faulted object records why. This is not the step to skip — the message usually names the cause directly. See Reading Infohub Logs.

The usual causes: a connection that cannot authenticate, a calculation that throws, a consumer whose destination rejects its writes, a source that times out.

Check whether it recovers. Some faults are transient — a source restarting, a brief network interruption — and clear on the next pass. A fault that persists across several passes is a real configuration or environmental problem.

Calculation-specific causes#

Calculated measures have their own failure modes, and the symptom pattern identifies them.

The gaps-on-shutdown-days pattern is worth memorising, because it is extremely common and looks like a data outage. Any measure whose name contains "per", "%", "rate", "efficiency", "yield", or "utilisation" is a division, and every division needs a guard. See The Zero Guard.

Event-derived measures#

An event-aggregated measure has additional ways to look stuck.

Events are not closing. If the end trigger is not firing, events remain open and their durations grow without limit. Every duration-derived measure above them is then wrong and grows.

No events in the interval. A legitimate absence, not a fault. Confirm against the event table before treating it as a problem.

The wrong anchor. A duration measure exceeding the interval length, or an availability outside 0–100%, is an anchor problem rather than a stuck measure. Use Active Duration for anything that must sum to the interval. See Analysing Data by Event.

Fixing it#

Once the cause is known:

A missing dependency — add it, then recalculate the affected range. The measure will not correct history on its own.

An unguarded division — fix the expression, then recalculate. Future intervals use the new logic; past ones keep the old failure until reworked.

A retry loop on one period — resolve the underlying error for that period. If the period genuinely cannot be produced, that fact needs to be established rather than left to retry indefinitely.

A stale cached calculation — the assembly is cached per calculation and rebuilt when the expression or a function changes. Where a measure behaves oddly after edits in the same session, recalculating the affected range after reopening resolves it.

A frozen period — move the freeze point back, recalculate, move it forward.

Prevention#

Declare dependencies honestly. The most common stale-value cause is a dependency the expression uses and the configuration does not declare.

Guard every division. Or standardise on a SafeDivide function so it cannot be forgotten. See Custom Functions.

Put limits on important measures. A limit that fires when a value goes implausible catches a stale or wrong measure far sooner than anyone reading a dashboard will.

Check the newest period across the model, not one measure. A scheduled check that the model's newest values are current catches a stuck measure while it is one period behind rather than a month.

Watch the log for repeats. The same error every pass is the clearest possible signal, and it is only visible if somebody looks.

Health checks you can run in SQL#

Two counts that say whether the engine is keeping up. Run them against the instance database; neither changes anything.

Measures waiting to be processed.

select count(*) from Measure where QueuePending = 1

A non-zero count is normal on a busy instance. What matters is that it moves: the same measures pending, pass after pass, are stuck. A deadlock named in the engine log and then followed by recovery is the engine retrying as designed, not a fault.

Event periods left open-ended after they were retired.

select count(*) from EventPeriod where PeriodEnd is null and Preferred = 0

A retired (non-preferred) period should have an end. One left open makes every duration measure derived from it grow without limit. The count should trend toward zero; a rising count is worth reporting.

Before you escalate#

1. Which of the three kinds — not advancing, advancing but stale, or faulted.
2. The exact period it stopped at, or the value it is holding.
3. The measure's configuration: retrieval type, interval, aggregation or expression, dependencies.
4. The lowest measure in the chain that is also affected.
5. Whether its engine is processing other content normally.
6. Flow event log entries around the period it stopped, with timestamps.
7. Whether the model was edited recently, and what was deployed.

See also#

• Diagnosing Missing Data
• Backfilling and Recalculation
• Monitoring Infohub and Its Health
• Tag-Level Calculations