Werk #20156: BI aggregation state REST API no longer blocks on compilation
| Component | BI | ||
| Title | BI aggregation state REST API no longer blocks on compilation | ||
| Date | Jul 13, 2026 | ||
| Level | Trivial Change | ||
| Class | New Feature | ||
| Compatibility | Compatible - no manual interaction needed | ||
| Checkmk versions & editions |
|
What changed
The BI aggregation state REST API endpoint (GET/POST .../aggregation_state)
no longer triggers a compilation check on every call. Instead, BI aggregation
compilation now runs as a background job that ticks once a minute.
Saving BI configuration in the GUI, or via the BI REST API (packs, rules, aggregations), still wakes up this background job immediately, so compiled results are typically ready again within a few seconds of a change instead of the full minute.
GUI pages showing BI aggregations are unaffected: they still compile on demand if needed, so you always see up-to-date state there. The background job and the GUI share the same compilation cache, so whichever runs first does the work.
After events that clear the compilation cache — a host reboot or an
omd update — the endpoint responds with HTTP 503 ("BI aggregations have not
been compiled yet") until the background job has finished its first
compilation, instead of misleadingly reporting that no aggregations exist.
Clients polling this endpoint must tolerate this transient 503 and simply
retry; the bundled special agent handles it as a regular connection error for
that cycle.
Why this matters
This REST API endpoint is polled once a minute by the Checkmk special agent that collects BI data. Previously, each of these calls could trigger a full synchronous compilation check, adding unnecessary load on busy sites with many BI aggregations. Moving this off the request path makes these polls faster and cheaper.
As a trade-off, the state returned by this REST API endpoint can now lag behind a configuration change by up to about a minute (or a few seconds, if the change was made on the same site), rather than always reflecting the very latest configuration. In addition, scripts consuming this endpoint should treat a 503 response as "retry later" rather than as an error (see above).