StatOSS

A self-hosted status page

The standalone version of StatOSS is one container and one YAML file. What it takes to run, what it includes, and what you take on.

config.yaml
checkIntervalSeconds: 60
sites:
  - name: Northwind
    host: status.northwind.example
    checkpoints:
      - name: Website
        url: https://northwind.example
      - name: API
        url: https://api.northwind.example/health
        expectedStatus: 200
        keyword: '"ok":true'
alerts:
  email: [email protected]
  slack: https://hooks.slack.com/services/...
A configuration file for the standalone: the sites, the URLs with what each should answer, and where alerts go. The README lists every field.

Running it

You need a box with Docker, a domain name pointed at it, and something in front to terminate TLS (Caddy does it in two lines). Then:

curl -o config.yaml https://raw.githubusercontent.com/kroqdotdev/statoss-standalone/main/config.example.yaml
# Edit config.yaml; the example explains every field.
docker run -d --name statoss --restart unless-stopped \
  -p 127.0.0.1:3000:3000 \
  -v "$PWD/config.yaml:/data/config.yaml:ro" \
  -v statoss-data:/data \
  ghcr.io/kroqdotdev/statoss-standalone:latest

The image is built for amd64 and arm64, and runs as user 1000. The page is up on the container's port from the first check. The README has the proxy and DNS steps and every configuration field. A live copy runs at statoss.com/standalone-demo, and an Uptime Kuma database imports with one command.

The configuration

One YAML file: the sites and their hostnames, the URLs to check with a method, headers, body, expected status, keyword and slow threshold each, the check interval (60 seconds unless changed), the SMTP server for alert emails, the Slack, Discord and webhook destinations, and maintenance windows. An incident is one file in the incidents folder, picked up without a restart. The data lives in one SQLite file in the /data volume, which is also the whole backup. There is no admin UI to secure.

What you take on

  • The box. When it is down, the checks stop and the status page is down with it. Put it on different infrastructure from what it watches.
  • One location. A failure seen from one server may be that server's own problem. The hosted service confirms every failure from a second network before it counts; the standalone cannot.
  • Backups, TLS, upgrades. Copy the SQLite file somewhere nightly, keep the certificate renewing, pull the image now and then.
  • HTTP only. Ports, DNS, ping, certificates, domains and heartbeats are hosted-only check types.

When to let us run it

When the page has to outlive your infrastructure, when you want a second opinion on every failure, when several people need their own logins, or when subscribers should get email. The hosted plans start free, and the export holds every check, so moving back is possible.