What Is Model Health?
The Model Health page is a single-page dashboard for diagnosing problems in your workspace. It surfaces calculation errors, modeling-time issues, and detailed calculation logs so you can fix problems before they show up in user-facing reports.
When something is wrong with the model, the side-navigation icon for Model Health turns red — giving admins a quick visual cue without having to open the page first.
Opening Model Health
Click the Model Health entry in the side navigation. The page opens to the Checklist tab by default. A Refresh action at the top right re-runs the underlying queries — useful when you've just made a change and want the latest picture.
Model Health is read-only. Nothing on the page modifies the model — you can browse safely.
Checklist Tab
The Checklist gives you the 30-second view of model health. It shows three lines, each with a green check, a red X, or a spinner if the underlying job is still running:
Calculation errors — whether the most recent calculation run produced any errors.
Modeling errors — whether static analysis has detected modeling-time issues that would prevent correct calculation.
Model loaded — whether the workspace has finished loading after the last calculation.
If everything is green, the model is in good shape. If any line is red, drill into the corresponding tab to investigate.
Dynamic Analysis Tab
Dynamic Analysis lists every variable that produced an error during the most recent calculation run. It's a runtime view: only problems that surfaced when the model actually executed appear here.
Each row shows:
Name — the variable that errored.
Error message — what went wrong.
Cell count — how many cells were affected.
Calculation time (ms) — how long the failed calculation took.
Every column is filterable. Use the column filters to narrow down to a specific variable, error pattern, or large slow calculation.
Static Analysis Tab
Static Analysis surfaces issues that can be detected without running the model — modeling-time problems and projected size impact. This catches things that haven't blown up yet but will once the model is calculated.
Each row shows:
Name — the variable being analyzed.
Errors — issues that will fail at calculation time (red).
Warnings — issues that won't fail but are likely to cause problems (yellow).
Amplification factor — how much the variable expands the cell space.
Cell count estimate — projected number of cells the variable will produce.
Use this tab to catch problems before users hit them, and to understand which variables are responsible for model size and performance.
Calculation Logs Tab
Calculation Logs is a chronological view of the latest calculation run. Each entry includes a timestamp, a log type, and a message — useful for tracking what happened during a run and when.
While a calculation is in progress, this tab auto-refreshes every two seconds so you can watch progress in real time. Once the run completes, auto-refresh stops.
Errors vs Warnings
Static Analysis distinguishes two severity levels:
Errors — the model will fail to calculate correctly until they're fixed. Always investigate.
Warnings — won't break the model, but indicate something likely to cause problems (e.g., unusually high amplification, deep formula chains). Worth reviewing during model maintenance.
Dynamic Analysis only shows errors — by definition, anything that surfaced at calculation time is a real failure.
Understanding Common Warnings
Static Analysis surfaces a few warning types repeatedly. Knowing what each one means makes it much easier to decide whether to act on it.
High Amplification Factor
A variable's amplification factor (sometimes called fanout) is how many cells get created in that variable for every value entered or imported on the variables it depends on.
When a variable has more dimensions than the source variables in its formula, every source value gets copied across all members of the extra dimensions — a Cartesian product. This can explode the cell count fast.
Worked example. Suppose you have two variables:
A — dimensions: [Versions, Years, Months]
B — dimensions: [Versions, Years, Months, Products]
If you write B = A * 3, then B takes every value in A and copies it for every member of Products. With 15 Products, B's amplification factor is 15. So if A has 100 values entered, B will have 1,500 calculated values.
Now add a third variable:
C — dimensions: [Versions, Years, Months, Products, Regions], also using A in its formula
C copies every A value over all combinations of Products × Regions. With 15 Products and 20 Regions, the amplification factor is 15 × 20 = 300. The same 100 values on A produce 30,000 cells on C.
This is very often the cause of slow reload times and out-of-memory errors — entering a single value on a source variable can trigger thousands of new cells in dependent variables.
Aggregation is fine. The reverse direction is not a problem. If you wrote A = B * 5 instead, A would simply have fewer values than B because they'd be aggregated to a lower dimensionality. Aggregation never amplifies.
What to check when you see this warning:
Does the result variable actually need the extra dimensions? Removing unused dimensions is the fastest fix.
Could the calculation move to a smaller variable upstream and aggregate later?
If the amplification is intentional (e.g., applying a global rate to a per-product variable), there may be nothing to fix — but be aware of the cell-count cost when the warning lights up.
Edge cases. The math gets more complicated when the "extra" dimensions are connected (e.g., allocating values from a Brands variable to a Products variable that's connected to Brands), or when formulas combine multiple source variables with different dimensionality. The general principle still holds — extra dimensions on the result variable amplify, regardless of how that's expressed.
Deep Formula Chain
The formula chain depth warning fires when a variable's formula depends on another calculated variable, which depends on another, and so on — long enough that calculation order or performance becomes a concern. The default warning threshold is 10 levels of chained calculation.
Long chains aren't always wrong. Some genuinely need to step through several intermediate calculations. But they're worth reviewing because they often grow accidentally:
Step-by-step intermediate variables that could be combined into one formula.
Unnecessary aliasing — variable B exists only to rename variable A.
Layered allocations where each layer became its own variable.
If each step in the chain is meaningful, the warning is informational. If the chain exists because of accidental intermediates, consolidating saves both calculation time and cognitive load when reading the model.
Typical Workflow
Notice the red Model Health icon in the side navigation.
Open the Checklist to see which area is failing.
Drill into the relevant tab — Dynamic Analysis for runtime errors, Static Analysis for modeling problems.
Filter to the affected variables, read the error or warning messages, fix the underlying issue.
Click Refresh to confirm the issue is resolved.
Permissions
Model Health is gated by a feature permission. By default it's available to admins and elevated roles only — the side-navigation entry is hidden for users without access.