Start with one service

Your first monitor.
Your first useful alert.

Warden checks whether a service is reachable and slower than normal. Run it yourself for free, then verify a real failure and recovery before trusting it with something important.

Open source under AGPL-3.0. No Project Helena account or payment required to self-host. You need Docker and an endpoint you control.

1. Run Warden locally

This example pins stable v0.9.0, stores data in a named volume and binds the dashboard to this computer only.

docker run -d --name warden \
  -p 127.0.0.1:9090:9090 \
  -v warden_data:/data \
  ghcr.io/projecthelena/warden:v0.9.0

Open localhost:9090 and create your admin account. For a remote server, Docker Compose or Kubernetes, use the installation guide. Set up HTTPS and access controls before exposing the dashboard publicly.

Already have a container named warden? Follow the installation guide instead of running a second instance against the same data.

2. Add one endpoint that matters

Choose a read-only health or readiness endpoint for your service. In Add Monitor, select HTTP, enter its URL and start with a 60-second interval. Set the expected HTTP status and timeout under Request Configuration.

Use a URL reachable from inside the Warden container. localhost inside Docker refers to that container, not your laptop or another service. A successful check should appear in the dashboard.

Warden also supports TCP, ping, DNS and Docker checks. Start with HTTP to learn the workflow; see monitor types and request settings.

3. Verify delivery, failure and recovery

  1. Open Settings → Notifications → Add Channel. Choose Slack, Discord, Telegram, email or a webhook.
  2. Send a test message and check the actual destination. Save the channel.
  3. Create a separate monitor for a disposable test endpoint. Make that endpoint return a failing status or stop its test service.
  4. Allow for failure confirmation and the sustained-outage notification window. Confirm a down alert arrives, then restore the endpoint and verify recovery.

Keep production running during the test. A channel test checks the connection to the provider; a controlled failure checks the entire monitoring path. Short outages may be recorded without notification, and recovery is announced only when the outage was announced. See notification behavior.

4. Review it after a week

Did it catch a problem? Were the alerts useful? Check the response-time baseline and tune thresholds against your service's actual behavior. With the defaults, adaptive latency needs at least 200 successful checks and the next hourly calculation; a new monitor does not have a learned baseline immediately.

Checks run from your Warden host. Browser journeys, global probes, application tracing and automatic SLA compliance reports are outside its current scope. The product guide explains where it fits.

If you tried it, tell us how it went: what you deployed it on, whether your first alert arrived, what was confusing and where you found Warden. Please leave out credentials and private endpoint URLs. Sharing feedback is optional.