The engine shipped with three monitor types. Over the next stretch it grew to eight. Each new probe had a design decision behind it.
HTTP#
URL uptime checks the URL is up and returns the expected status. API checks send any request and assert on status, response time, JSONPath, headers, or body text. Browser checks run a real Playwright .spec.ts, the same script a team writes for e2e tests.
Sockets, not HTTP#
A monitoring tool that only knows HTTP misses half the stack, so some probes talk to a socket directly.
- TCP connects to
host:port, measures latency, and can grab and assert on the banner (SSH, SMTP, Redis, IMAP). It waits for a full multi-packet banner before deciding, so a split response does not fail early. - UDP sends a datagram and optionally waits for a reply. Good for DNS, NTP, and custom services.
- Database confirms Postgres, MySQL, or Redis speaks its protocol. No credentials stored, no query run: the question is "is it up," and a monitoring box should not hold your DB passwords.
- TLS runs the handshake and fails on near-expiry (30-day default). Chain, hostname, and CN regex checks are opt-in, so it stays self-signed-friendly.
Heartbeat#
Your cron job sends a ping to a URL each time it runs. If the next ping is late, oo-workers marks the monitor OVERDUE and alerts you once. Nothing reaches out and no port is exposed, so it can watch background jobs that have nothing to check from the outside.
One engine#
Every type, HTTP or socket or heartbeat, produces the same execution shape: status, latency, pass or fail. So alerts, status pages, and run history work identically across all eight, and a ninth probe inherits them for free.
All eight run self-hosted from one docker compose up. oo-workers is the Apache-2.0 engine behind ObserveOne.