OneUptime ships: cloud auto-discovery. Your existing OpenTelemetry collector already sends Azure Monitor, CloudWatch and Cloud Monitoring metrics. OneUptime now reads those and inventories your cloud estate: every VM, load balancer, bucket and database gets a page with its own metrics, and you can build a monitor on any of them. No cloud credentials to hand over. No agents to install. Just the metrics you already send. Open source: github.com/OneUptime/oneuptime

AI is moving into incident response, and your telemetry is its input. Sovereign AI starts with the input: a model that runs where your logs live, or at minimum a redaction step before anything leaves the network. If you can't see what the model read, you can't audit why it said what it said.

Your status page is only as sovereign as its hosting. If it lives on the same vendor as the app, one outage takes both down, and your users can't even find out. Host it somewhere boring and separate: a cheap VPS, a static host, somewhere that dies on a different day.

Your observability stack sees more of production than any other system you run. That's why sovereignty starts with who built it: open source on your own infrastructure, where you can read the code and watch where the data goes. The most invasive tool you operate should be the one you can verify.

Choose a monitoring tool for how you use it, not the format it locks you in. Metrics and traces in an open, queryable format keep the tool swappable. The day that data is only one vendor's, a tool decision quietly becomes a migration project. Own the format.

Open-source alerting means a 2am page is something you can check, not something you have to believe on faith.

An SLO is a promise with a number on it. When your team and your users read the same number, reliability stops being an opinion.

New outages feel like mysteries until someone says, 'this one broke the same way as March.' That memory is worth keeping in records you control.

OneUptime 14.0.12 ships a Kubernetes AI agent. It is a small service that runs inside your cluster, and it lets the AI SRE investigate incidents with kubectl directly: list and describe resources, read logs and events. Read-only by default. The interesting part is what happens between the AI and your API server. Every command is re-checked in-cluster before it runs. kubectl as an argument list, never through a shell. Secret reads are never allowed. Writes happen only if you opt in, and only in the namespaces you named. If you self-host, the AI works on your telemetry in your cluster, under rules you set. That is the shape we want sovereign observability to take.

OneUptime Docs

Kubernetes Agent

The OneUptime Kubernetes Agent is a pre-packaged Helm chart that installs an OpenTelemetry-based collector pipeline on your cluster. It ships node,...

Sometimes the most sovereign act is a fork. When the tool you depend on stalls, the freedom to pick up the work yourself is what keeps the lights on.

Ask any team who holds their DNS, their certs, and their logs. If every answer is the same company, you're renting, not running.