Wanepia¶
Service catalog, uptime monitoring, and smart alerting — all in one.
Wanepia lets you model your infrastructure as a catalog of typed entities, attach health checks, and route alerts through any channel when things go wrong.
What it does¶
Define blueprints (e.g. API, Database, Worker) with custom fields, then register entities that conform to each blueprint. Your whole fleet lives in one structured, queryable catalog.
Attach health checks — HTTP, TCP, TLS, or DNS — to any entity. Checks run on configurable intervals; failures accumulate against a threshold before a state change fires. No flapping.
Notification policies define cooldowns, recovery alerts, and repeat intervals. Channels deliver alerts to Slack, Discord, webhook endpoints, NATS subjects, or ntfy topics — any combination, per check.
Every state transition is a permanent, immutable audit log. Raw check results are stored with millisecond latency and rotated by partition — fast queries, controlled storage.
Architecture at a glance¶
┌──────────────┐
Browser / CLI │ API Service │ :8080
└──────┬───────┘
│ REST + API key
┌──────────▼──────────┐
│ PostgreSQL │
└──────────┬──────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌──────▼─────┐ ┌──────▼─────┐ ┌─────▼──────┐
│ Generator │ │ Worker │ │ Notify │
│ (scheduler)│ │ (executor) │ │ (alerts) │
└──────┬─────┘ └──────┬─────┘ └────────────┘
│ │
└──────┬───────┘
│ NATS
CheckJob / StateChangeEvent
Four Go microservices communicate over NATS. The API is the only process that speaks HTTP. Workers can scale horizontally — NATS queue groups prevent duplicate execution.
Next steps¶
- Quickstart — monitor your first service in five minutes
- Blueprints — model your service types
- CLI Reference — full
wnpcommand reference