Skip to content

Quickstart

Monitor your first service in under five minutes.

Try the demo

No account needed. Browse a live catalog at demo.wanepia.com to see what a running setup looks like.

1. Sign up

Create an account at app.wanepia.com.

On first login, your tenant and initial API key are created automatically. You can create additional keys under Settings → API Keys.

2. Install the CLI

curl -Lo wnp https://github.com/wanepia/wnp/releases/latest/download/wnp-$(uname -s)-$(uname -m)
chmod +x wnp && sudo mv wnp /usr/local/bin/

brew install wanepia/tap/wnp

Configure it with your API key:

wnp config set-url https://api.wanepia.com
wnp config set-token <your-api-key>

Verify it works:

wnp status show

3. Create a blueprint

Blueprints define the types of services in your catalog. Start with one for HTTP APIs:

wnp blueprints create --slug api --name "HTTP API" --desc "Public-facing services"

You can add custom fields (team, repo URL, on-call, etc.) later via the dashboard or the API.

4. Register an entity

An entity is a specific instance of a blueprint — one running service, database, or worker.

wnp entities create api --slug payments-api --name "Payments API"

5. Add a health check

Attach an HTTP check to the entity:

wnp checks create \
  --entity payments-api \
  --type http \
  --url https://api.example.com/health \
  --interval 60 \
  --status 200 \
  --threshold 3

The check runs every 60 seconds. After three consecutive failures the entity transitions to down and any configured notifications fire.

6. View status

wnp status show

  1 up   0 degraded   0 down

  NAME           BLUEPRINT   SLUG           STATUS
  Payments API   api         payments-api   up

7. Set up alerting (optional)

Wire a Slack webhook so you get notified on state changes:

wnp checks alert <check-id> \
  --type slack \
  --config url=https://hooks.slack.com/services/...

See Notifications for cooldowns, recovery alerts, and all supported channels.

Monitoring private services

If your service is behind a firewall, VPN, or inside a Kubernetes cluster, use a push check instead. Your agent probes the service and posts results to Wanepia — no inbound connections needed.

# Create the check
wnp checks create \
  --entity postgres-primary \
  --type push \
  --name "Postgres reachability" \
  --interval 60 \
  --threshold 1

# Your agent posts a result (run this from inside your network)
curl -X POST https://api.wanepia.com/v1/checks/$CHECK_ID/results \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"success": true, "latency_ms": 12}'

See Push Agents for shell, Docker, and Kubernetes deployment patterns.

What's next