Operational visibility · Monitoring integration
Lab Status
Monitoring adapters and diagnostic APIs that bring together Kuma readings, Kubernetes readiness, and deployment records. Each source keeps its own timestamp so an older reading is not mistaken for a current one. The linked private app is the upstream Uptime Kuma console.
Implementation scope
Custom work covers source adapters, a shared status format, freshness tracking, failure and recovery tests, and fixed-target HTTP probes. Diagnostics run on demand; public profile pages do not poll or display live service status.
Kuma · K8s · Health checks
Implementation evidence
Failure and recovery
API checks simulate a monitoring outage and subsequent recovery. A failed refresh retains the last successful check time; recovered readings receive a new timestamp.
Basis: Monitoring API failure/recovery fixtures
Independent observations
Tests cover per-source freshness and partial cluster readiness. A current deployment record cannot make an older service observation current.
Basis: Status contract unit and API checks
Bounded probe traffic
Concurrent refreshes share upstream work. Fixed-target HTTP probes use a shared deadline and cache negative results; integration checks exercise cache behavior and recovery.
Basis: HTTP probe unit and integration checks
System flow
- KumaConfigured monitor readings
- KubernetesNode and workload readiness
- Deployment recordsRelease activity
Independent source readings
Custom integration
Source adapters
Refresh configured sources concurrently with bounded requests.
Per-source results
Data contract
Normalized readings
Retain each source's check time, freshness, and last successful reading.
Diagnostic response
Custom integration
On-demand diagnostics
Expose scoped observations without automatic public-page polling.
Sources are independently optional. Fixed-target HTTP entry probes form a separate diagnostic path and do not verify authenticated application workflows. The linked private app is the upstream Kuma console.
Design decisions
Keep observations separate
A recent release, a ready node, and an available application answer different questions. The API reports them separately, so a successful deployment cannot mask an unavailable monitor or an older service reading.
Make data age visible
When a refresh fails, the last successful reading retains its timestamp. Callers can distinguish an older observation from a new failure. Missing telemetry alone does not establish whether the application is healthy or down.
Bound the work
Concurrent requests share refresh work, and short caches include failed results to avoid repeatedly probing an unavailable service. Recovery may therefore appear after a brief delay. HTTP probes use fixed targets, a shared deadline, and no redirect following.
Access and limitations
The linked app is the private Uptime Kuma console. HTTP diagnostics confirm only entry reachability, including redirects and protected access; they do not verify a signed-in application or its internal dependencies. Cluster and deployment diagnostics require configured monitoring sources.
Updated