Two simple flows. No magic. No inbound ports.

How an uptime check actually runs

You add a monitor: a URL, a TCP port, a DNS record, an ICMP target, or a Tor .onion address. From that moment, a worker in each region you picked starts running it on the interval you chose. Here's the loop:

1. 1

   Lease

   There's no central scheduler pushing work out. Each region's worker polls our control plane over HTTPS and leases the checks that are due for its region. The lease is atomic, so two workers never run the same check, and a slow or offline region simply stops leasing without holding up any other region.

2. 2

   Probe

   The regional worker (a tiny, stateless probe) executes the check: an HTTP GET, a TCP connect, a DNS resolve, an ICMP echo, or a Tor connection for .onion targets. It never touches our database. Every customer URL is resolved once and locked to that IP for the duration of the request, so DNS rebinding can't redirect a check at our own infrastructure.

3. 3

   Report

   The worker posts the result back to our ingest endpoint over HTTPS, signed with a secret it shares with the control plane. Every result lands in a time-series store, partitioned by time so history stays fast to query.

4. 4

   Roll up

   If the monitor is probed from multiple regions, your configured down-rule decides whether one region failing means the site is down or your network path is. The choices are any / all / majority / N-of-M. The overall status is what your dashboard and alerts see.

5. 5

   Alert (only on transitions)

   A genuine state change (up → down, down → up, or an edge-triggered cert-expiry crossing) fans out to every channel you've routed to that monitor. A flapping monitor doesn't page you; the state machine debounces it.

ensju.com/app/monitors/ensju.com

The shape of it

Stateless probe workers in every region, each reaching the control plane over outbound-only HTTPS, they lease work and post results, and never accept an inbound connection themselves. The database never faces the public internet. A dispatcher fans alerts out to whatever channels you've connected.

1. You

   Watch your sites, APIs, and servers from the web app or mobile companion; alerts reach you on email, Slack, Discord, and more.

2. Ensju

   The Next.js app + lease endpoint hands due checks to stateless probe workers and stores results in an org-scoped time-series database.

3. Probe workers

   One per region, they probe your sites over HTTPS / Tor and post signed results back, no database or queue port is exposed to the internet.

4. Your servers

   The Ensju agent reports metrics outbound-only over token-authed HTTPS, so there's nothing inbound to open.

┌─────────────────┐                                  ┌────────────────────┐
│ Your browser    │                                  │ Your sites / APIs  │
│ / mobile app    │◀───── alerts (email,             │ HTTP · TCP · DNS · │
└────────┬────────┘       Slack, Discord, …) ───┐    │ ICMP · .onion      │
         │                                      │    └─────────▲──────────┘
         │ HTTPS (logged in)                   │              │ probes
         ▼                                      │              │ over HTTPS / Tor
┌──────────────────────────── Ensju ─────────────────────────────────────────┐
│                                                │                           │
│ ┌───────────────────┐    ┌─────────────────┐   │   ┌──────────────────────┐│
│ │ Next.js app + API │    │ Notification    │   │   │ Probe workers        ││
│ │ + lease endpoint  │───▶│ dispatcher      │───┘   │ (one per region,     ││
│ │ (ensju.com)       │◀───┤                 │       │  stateless probe)    ││
│ └─────────┬─────────┘    └─────────────────┘       └──────────┬───────────┘│
│           │                    ▲                              │            │
│           ▼                    │ lease checks + post results  │            │
│   ┌──────────────┐             │ outbound HTTPS, signed       │            │
│   │ Database +   │             └──────────────────────────────┘            │
│   │ time-series  │     no database or queue port on the public internet    │
│   │ (org-scoped) │                                                         │
│   └──────────────┘                                                         │
│                                                                            │
└──────────────────────────────────▲─────────────────────────────────────────┘
                                   │ HTTPS POST (token-authed, outbound only)
                                   │
                          ┌────────┴─────────┐
                          │ Your servers     │
                          │ (Ensju agent)    │
                          └──────────────────┘

• Every business table is org-scoped. Each request runs locked to a single organization, and every query is filtered by its org id, so one customer's data never crosses into another's.
• The probe workers don't connect to your data plane at all. A worker only ever talks to two HTTPS endpoints (one to pick up the checks due in its region, one to hand back results), both locked behind a shared secret. It has no database access and only ever sees the checks it's actively running.
• Workers reach us, never the other way around. A region is just a VM making outbound HTTPS calls; it exposes no inbound ports, and there's no queue or database port anywhere on the public internet to scan or attack.
• The probe is the only thing that touches your URLs. All HTTP/TCP/DNS/ICMP dialing goes through an SSRF-safe blocklist that rejects RFC 1918, loopback, link-local, AWS metadata, and known-bad ranges before the connection opens. We'd rather refuse to probe a misconfigured monitor than ever probe somebody's private network from inside a customer's account.

Your data is your data

Monitoring tools see a lot of your infrastructure. We treat that the way you'd want us to.