MishkaCmsCore.Runtime.SiteHealth (Mishka CMS Core v0.0.1)

Copy Markdown View Source

Read-only health roll-up for a single Site, for the admin Sites table's expanded row. A Site is an aggregate (it owns Pages/Layouts/Components/ErrorPages/Stylesheets/ JsHooks + its CSS/JS bundles + a serving state), so this is a dashboard, not the linear pipeline used per-record by MishkaCmsCore.Runtime.RuntimeStatus.

Signals (all cheap, computed on expand and on each realtime refresh):

  • serving state — straight off the loaded Site record, and whether it is offline: offline_by is MishkaCmsCore.Settings.offline_by/1, so the site's own switch and the Global one are told apart
  • compile jobs since this node booted, grouped per target into in-progress, unrecovered (the target's latest job failed) and recovered (failed earlier, but a later job succeeded) — one oban_jobs query matched on the site's immutable site_id (all jobs carry it). A job from before the boot is left out: the boot cancelled it and compiled from the database itself (MishkaCmsCore.Runtime.Handlers.BootHandler.booted_at/0)
  • whether the app's Oban rescues jobs a restart interrupts (BootHandler.lifeline?/0)
  • per-resource active/inactive/archived counts — one UNION query across the 6 runtime tables (site-specific records only)
  • CSS/JS bundle presence + freshness — O(1) AssetsState ETS reads
  • recent activity — last few unified-log entries for the site (Activity.Query)

The derived headline is :inactive → :offline → :attention (unrecovered) → :working (in progress) → :recovered → :healthy. Red (:attention) is reserved for a target whose latest job is still failed; a target that failed and then succeeded is a soft orange :recovered, because a later success supersedes the old failure (a fix saved after a failed save).

Rendered by MishkaCmsCoreWeb.Live.Admin.Components.SiteHealthPanel.

Summary

Functions

Compute the health map for site (a loaded Site record).

Functions

compute(site)

Compute the health map for site (a loaded Site record).