A monitoring result becomes useful when people can understand it. This platform connects synthetic checks, explicit state rules, and automated publishing in a workflow that can be reviewed in code.
Grafana synthetic checks
Python component-state logic
GitHub Actions → GitHub Pages
Monitoring, status classification, and public communication are different jobs. When the rules live in separate dashboards and manual steps, it becomes harder to explain why a component changed state.
The platform brings those decisions into a repeatable workflow: query reachability and latency, evaluate each component against its thresholds, and publish the resulting status report.
The implementation separates configuration, interpretation, and publication so each can be reviewed on its own.
A central configuration describes endpoints, thresholds, and components. A reconciliation workflow provisions monitoring resources and generates the configuration consumed by the status jobs.
Changes have a source history. The reconciler still needs to cover every request setting that can affect a check.
Review the configuration workflowReachability and latency are evaluated separately, with the more severe result determining component state. Individual checks can override the default thresholds.
Tests cover exact threshold boundaries, missing metrics, component overrides, and the overall state calculation.
Read the state-evaluation testsThe monitoring job writes a JSON report and deploys the static status site through GitHub Pages. A separate workflow can synchronise component states and incidents with Atlassian Statuspage.
Status updates deploy as artifacts without committing each measurement back to the repository.
Follow the publishing workflowThe public repository exposes the rules, tests, and workflows behind the status surface.
The report retains reachability, latency, and observation timestamps alongside the classification.
Thresholds and their boundary tests can be inspected together, including per-component overrides.
GitHub Actions generates and deploys the report through the same workflow on each run.
These are demonstrated implementation capabilities. The project does not establish a customer uptime result or an incident-response guarantee.
A failed synthetic request is an observation from a particular probe and request profile. It cannot, on its own, establish how every visitor experienced the service.
The current state engine classifies missing metrics as a major outage. That avoids reporting an unobserved component as healthy, but it can also turn a monitoring-data problem into a public availability signal.
Probe configuration, freshness, and the rules for incident communication deserve the same care as the status calculation.
Inspect the current state engineThe repository includes implementation, tests, configuration, and an operating guide.
Open the status-platform repositoryView the public status pageConnect the checks, decision rules, and operating response your team depends on.
Discuss reliability & monitoring