Hey everyone 
I wanted to share a quick update regarding our progress on setting up an Ansible community status page. We recently wrapped up a research spike evaluating two primary candidates mentioned by the community for the status page: Uptime Kuma and Gatus.
After a thorough deep dive into both tools, we’ve decided to go with Gatus. Since we want to be as transparent as possible, here is a quick summary of our rationale, focusing on long term maintenance and infrastructure as code (IaC).
The Core Requirement: Minimal Moving Parts and High Automation
Our overriding constraint for this project is to minimize operational burden and avoid adding unnecessary moving parts to the architecture. We heavily favor Infrastructure as Code (IaC). We want our status page to be version controlled, code reviewed, and deployed entirely via Ansible rather than manually clicked together in a UI.
Why Uptime Kuma Fell Short for Our Use Case
Don’t get us wrong, Uptime Kuma is a fantastic, incredibly popular project with a massive community. However, its core architecture presents a few major roadblocks for how we want to build our infrastructure:
-
UI Driven and Stateful: Uptime Kuma relies completely on a Web UI and stores its state inside an SQLite database. This means there is no config file to track via Git diffs or manage natively through Ansible.
-
The IaC Compatibility Gap: There are third party tools out there to automate Uptime Kuma, like the uptime-kuma-api Python wrapper and the lucasheld.uptime_kuma Ansible collection. However, both have been entirely unmaintained since mid-2023. They only support Uptime Kuma up to version 1.23.2, whereas the tool is currently on version 2.4.0. Relying on broken, outdated wrappers completely goes against our goal of minimal maintenance.
-
No Native REST API: Uptime Kuma explicitly chose to build on WebSockets/Socket.IO instead of a traditional HTTP REST API, making standard programmatic queries highly impractical without a heavy SDK wrapper.
Why Gatus is a Great Fit
Gatus takes a developer first, configuration as code approach that aligns perfectly with our ecosystem:
-
Native Ansible Integration: Gatus is entirely driven by a single YAML configuration file. This means we don’t need any specialized external collections or complex Python SDKs. We can use core modules like ansible.builtin.template to manage the whole thing. Adding or removing a monitored service, like Galaxy or our various bots, becomes a simple edit to a role variable.
-
Low Operational Complexity: It compiles down to a lightweight Go binary with a tiny resource footprint. It even supports hot config reloads natively, so when Ansible updates the YAML file, Gatus picks up the changes instantly without needing a service restart.
Another big win for Gatus is how cleanly it handles external alerts. While neither tool has a specialized Discourse integration out of the box, Gatus features a powerful, native alerting.custom webhook provider.
It would allow us to write a clean, templated HTTP POST body directly inside our version controlled YAML configuration file that targets the Discourse REST API (POST /posts.json). We can leverage a dedicated forum bot account, keep the API credentials securely encrypted using Ansible Vault, and cleanly fire alerts or recovery notices straight into a dedicated, muted forum category like #infrastructure-status. By default, this category will be muted so it won’t clutter the /latest feed for everyone, but users who want to receive these alerts can easily watch or subscribe to the category themselves. This completely avoids the need for heavy third party plugins and keeps everything in one managed file.
Next Steps
We will continue to chip away at this in the background. We’d love to hear your thoughts on this! Let us know if you have any questions or suggestions.
Thanks all! 
).
