[opensourcedex]

Wachd is a free, open source monitoring & observability project written in Go and released under a custom open-source licence. It has 38 GitHub stars, 5 forks and 5 open issues, and was last pushed 5 hours ago. On this registry it ranks #95 of 97 tracked projects in Monitoring & Observability, with 5 head-to-head comparisons available. It gained 1 stars over the last 6 tracked days.

What is Wachd?

Wachd is a self-hosted, air-gapped alert intelligence platform that uses AI to turn monitoring alerts from tools such as Grafana, Datadog, Prometheus, and Splunk into a plain-English root cause diagnosis for the on-call engineer.

What it is

Wachd is a Go application that sits between your monitoring stack and your on-call rotation. It receives alert webhooks over HTTPS, gathers supporting context, and routes a diagnosis to whoever is on call. It lives in the Infrastructure & Operations / Monitoring & Observability category, and rather than replacing a monitoring system, it consumes the alerts those systems already produce. It replaces the manual first pass an engineer performs at 3 a.m. — opening dashboards, reading recent commits, grepping logs, and guessing at correlation — with an automated pipeline that emits a probable cause and a suggested action.

The concrete problem it solves is context assembly under time pressure. When an alert fires, Wachd fetches recent commits, error logs, and metric history around the alert time, strips personally identifiable information from that material before any analysis runs, correlates the events into a causal timeline, looks up the on-call owner for the affected team, and notifies them through Slack or email. No agents run inside your application clusters; Wachd receives alerts inbound via HTTPS and calls your monitoring APIs outbound, so the data remains in your infrastructure. Analysis is delegated to Ollama, which allows fully local, air-gapped deployments where no alert context leaves the network.

Key capabilities

  • Accepts alert webhooks from Grafana, Datadog, Splunk, or any compatible source at POST /api/v1/webhook/{teamId}/{secret}.
  • Collects context from GitHub, Loki, and Prometheus around the alert timestamp, including recent commits, error logs, and metric history.
  • Sanitizes PII from all collected context before analysis, so sensitive material is never passed to the model.
  • Correlates events into a causal timeline and produces a plain-English probable cause with a suggested action.
  • Runs root cause analysis through Ollama, configured with AI_BACKEND=ollama, OLLAMA_ENDPOINT, and OLLAMA_MODEL=llama3.2 for local and air-gapped deployments.
  • Buffers work through a Redis queue in front of a worker process, decoupling webhook ingest from analysis latency.
  • Ships enterprise authentication covering local users, SSO via OIDC (Microsoft Entra, Okta, Google Workspace), local groups, AD group to Wachd team mappings, and Bearer API tokens; first startup auto-creates a superadmin whose credentials print to the server log.

Who uses it and how

  • On-call engineering teams that want the first diagnostic pass automated and delivered in the same channel they already monitor, Slack or email.
  • Air-gapped and restricted-network operators who cannot send alert context to a hosted AI service and therefore run Ollama locally.
  • Organizations with PII in logs and metrics that need sanitization enforced as a pipeline stage rather than a human promise.
  • Enterprises using Microsoft Entra, Okta, or Google Workspace that map existing directory groups onto Wachd teams instead of maintaining a second user list.
  • Small and mid-sized teams: the project runs a Founders Program offering ten lifetime SMB licences at no cost in exchange for serious deployment and feedback, and a hosted sandbox at demo.wachd.io provides a no-install evaluation from an email address.

Getting started

The README documents a Compose-based local path: run make docker-up to start PostgreSQL and Redis, run make deps to install Go dependencies, copy .env.example to .env, and then run make dev to start the API server, worker, and web dashboard. A hosted demo is available at demo.wachd.io for evaluation without a cluster.

How it compares

Wachd does not compete with the monitoring tools it consumes; Grafana, Datadog, Prometheus, and Splunk remain the alert sources, and Wachd adds the correlation and diagnosis layer above them. The registry listing names no direct alternative offering the same self-hosted, air-gapped root cause analysis, so no head-to-head licence or pricing comparison can be drawn from the available facts.

When to use it — and when not to

Adopting Wachd means operating PostgreSQL, Redis, an SMTP relay or Slack webhook, and an Ollama instance if you want local analysis, plus reachable APIs for whichever context sources you enable; that is a real operational surface for a team with no infrastructure owner. Teams that want a fully managed service, or that will not run a database, queue, and model runtime, should look elsewhere. Verify the licence before adoption: the registry records NOASSERTION while the README carries an Apache 2.0 badge, and the project is small — 38 stars, 5 forks, 5 open issues, an empty topic list, and no tagged release details in the listing.

project readme (upstream, from github) — read inline

Wachd

Self-hosted alert intelligence platform with root cause analysis.

Wachd receives alerts from your monitoring tools (Grafana, Datadog, Prometheus) and automatically collects context, sanitizes PII, correlates events, and routes a plain-English diagnosis to the on-call engineer.

License Go Version Go Report Card Discord GitHub Stars Live Demo

If Wachd is useful to you, a ⭐ on GitHub helps other engineers find it.

Try the live demo → — no install, no cluster, sandbox from just an email.

Wachd demo — on-call check, alert fire, AI root cause analysis

Founders Program — 10 lifetime SMB licenses We're giving 10 engineering teams a lifetime Wachd SMB license at no cost. Deploy it, use it seriously, tell us what's broken. Claim a slot on Discord or email [email protected].

How It Works

When an alert fires, Wachd:

  1. Receives the webhook from Grafana, Datadog, Splunk, or any compatible source
  2. Fetches context — recent commits, error logs, metric history around the alert time
  3. Strips all PII from the collected context before any analysis
  4. Runs root cause correlation to build a causal timeline
  5. Looks up who is on-call for that team
  6. Sends a notification with the probable cause and suggested action

No agents run in your application clusters. Wachd receives alerts inbound via HTTPS and calls your monitoring APIs outbound. Your data stays in your infrastructure.

Architecture

Your Monitoring (Grafana / Datadog / Prometheus)
    │
    └──► POST /api/v1/webhook/{teamId}/{secret}
              │
              ▼
         Redis Queue
              │
              ▼
         Worker Process
           ├── Collect context (GitHub, Loki, Prometheus)
           ├── Sanitize PII
           ├── Correlate events → causal timeline
           ├── Run root cause analysis (Ollama)
           └── Notify on-call engineer (Slack + Email)

See docs/ for architecture diagrams.

Authentication

Wachd includes an enterprise authentication system with local users, SSO (OIDC), and API tokens. On the first startup a superadmin account is created automatically and the credentials are printed to the server log.

See docs/authentication.md for the complete guide, including:

  • Bootstrap admin setup
  • Local user management
  • Password policy configuration
  • Local groups and team access
  • SSO provider configuration (Microsoft Entra, Okta, Google Workspace)
  • Group mappings (AD group to Wachd team)
  • Kubernetes secrets setup

See docs/api-tokens.md for programmatic API access using Bearer tokens.

Prerequisites

  • Go 1.24+
  • Docker and Docker Compose
  • Make

Quick Start

1. Start infrastructure

make docker-up

Starts PostgreSQL and Redis in Docker.

2. Install dependencies

make deps

3. Configure environment

Copy the example environment file and fill in your values:

cp .env.example .env

Key settings in .env:

DATABASE_URL=postgres://wachd:wachd@localhost:5432/wachd
REDIS_URL=redis://localhost:6379

# Trusted ingress/proxy CIDRs for webhook client IP extraction.
# Empty means X-Forwarded-For is ignored and rate limiting uses RemoteAddr.
TRUSTED_PROXY_CIDRS=

# Analysis backend (Ollama for local, air-gapped deployments)
AI_BACKEND=ollama
OLLAMA_ENDPOINT=http://localhost:11434
OLLAMA_MODEL=llama3.2

# Optional — notifications
SLACK_WEBHOOK_URL=https://hooks.slack.com/services/...
SMTP_HOST=smtp.example.com
SMTP_PORT=587
[email protected]
SMTP_PASS=your-smtp-password

4. Start the server, worker, and web dashboard

make dev

Opens:

  • API server on http://localhost:8080
  • Web dashboard on http://localhost:3000

5. Send a test alert

make test-webhook

Deploy with Docker Compose

The fastest way to self-host Wachd on a single server or VPS. No Kubernetes required.

git clone https://github.com/wachd/wachd
cd wachd
make compose-up

If you have a local .env from development: DATABASE_URL and REDIS_URL use localhost hostnames, which won't resolve inside Docker. Either remove the .env file (the compose defaults use Docker service names) or update those two values to postgres:5432 and redis:6379.

First run — get your admin credentials:

On the very first startup, Wachd creates a superadmin account and prints the credentials once to the server log. Retrieve them with:

docker compose logs wachd-server | grep -A 6 "BOOTSTRAP ADMIN"

You will see:

║  Username: wachd_admin                        ║
║  Password: <generated-password>               ║

Log in at http://localhost:3000 and change the password immediately when prompted.

Before going to production: generate a unique encryption key and set it in .env:

cp .env.example .env
echo "WACHD_ENCRYPTION_KEY=$(openssl rand -hex 32)" >> .env

The default key in docker-compose.yml is public — anyone using it can decrypt credentials stored in your database. Fine for local evaluation, not for production.

By default Wachd uses Ollama for AI analysis (no external API calls). Pull a model after the stack starts:

docker exec wachd-ollama ollama pull llama3.2

To use OpenAI instead, copy .env.example to .env and set:

AI_BACKEND=openai
OPENAI_API_KEY=sk-...

Then make compose-up again.

To stop:

make compose-down

Why not docker compose down directly? The app services (wachd-server, wachd-worker, wachd-web) use the app profile. Running docker compose down without --profile app skips them, leaving the network in use. Always use make compose-down — or docker compose --profile app down if you prefer the raw command.

Project Structure

wachd/
├── cmd/
│   ├── server/          # Webhook receiver and REST API
│   └── worker/          # Background job processor
├── internal/
│   ├── store/           # PostgreSQL models and queries
│   ├── queue/           # Redis job queue
│   ├── collector/       # Context collection (GitHub, Loki, Prometheus)
│   ├── sanitiser/       # PII removal — 21 regex patterns
│   ├── correlator/      # Event correlation and causal timeline
│   ├── oncall/          # On-call schedule and rotation engine
│   ├── notify/          # Slack and email notifications
│   └── ai/              # Pluggable analysis backend (Ollama)
├── web/                 # Next.js 15 dashboard (TypeScript, Tailwind)
├── helm/wachd/          # Helm chart for Kubernetes deployment
├── scripts/             # Development and review utilities
└── docs/                # Architecture diagrams

Makefile Commands

make help          # Show all available commands
make dev           # Run server + worker + web dashboard
make server        # Run API server only
make worker        # Run background worker only
make web           # Run web dashboard only
make test          # Run all tests
make build         # Build server and worker binaries
make test-webhook  # Send a test alert to the local server
make logs          # Follow Docker Compose logs
make clean         # Remove build artifacts

API Reference

Receive an alert

POST /api/v1/webhook/{teamId}/{secret}

Accepts JSON payloads from Grafana, Datadog, Prometheus Alertmanager, or any custom source.

Incidents

GET  /api/v1/teams/{teamId}/incidents
GET  /api/v1/teams/{teamId}/incidents/{incidentId}
POST /api/v1/teams/{teamId}/incidents/{incidentId}/ack
POST /api/v1/teams/{teamId}/incidents/{incidentId}/resolve
POST /api/v1/teams/{teamId}/incidents/{incidentId}/snooze

On-call

GET /api/v1/teams/{teamId}/oncall/now
GET /api/v1/teams/{teamId}/schedule
PUT /api/v1/teams/{teamId}/schedule

Utility

GET /api/v1/health    # Liveness probe
GET /api/v1/metrics   # Prometheus metrics endpoint

Kubernetes Deployment

Wachd ships with a production-grade Helm chart.

Prerequisites

  • PostgreSQL 15+ (AWS RDS, Azure DB for PostgreSQL, GCP Cloud SQL, or self-hosted)
  • Redis 7+ (AWS ElastiCache, Azure Cache for Redis, or self-hosted)
  • Kubernetes 1.26+
  • Helm 3.10+
  • cert-manager v1.13+ installed in the cluster

Optional prerequisites (required only if

readme truncated — read the full docs on github

Frequently asked questions

Is Wachd free to use?

Wachd is open source. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does Wachd do?

AI-powered root cause analysis for on-call alerts, self-hosted and air-gapped

What is Wachd written in?

Wachd is primarily written in Go. Its source is publicly available at https://github.com/wachd/wachd, and it has 38 GitHub stars.