Design of the checkin service
Making a service that is radically simple and reliable
Triple Pat exists to tell you when your alerting has gone quiet, so the service itself has to stay up when other things do not. Two design choices do most of that work, and the rest is buying many copies of a simple thing.
One data structure
The critical insight is that a service collecting (timestamp, uuid)
pairs, where only the most recent timestamp for a given UUID matters, is
maintaining a
CRDT.
All the work databases do to prevent conflicting updates goes out the
window. Every server can accept writes, servers can exchange what they have
in any order, and they all converge on the same answer without anyone
worrying about the CAP theorem.
One credential
The same taste for simplicity governs how timers are named. A timer’s UUID is both its identifier and its only credential, so it has to be unguessable. We use version 4 UUIDs, generated server-side, which gives 122 random bits - the right tool when an identifier must double as a credential. There is no account or password on top, and because the whole credential fits in a URL or an email address, anything that can deliver a request can check in.
Many front doors
Because every server accepts check-ins and reports the same state, we can run as many as we like, and we place them so that no single failure silences your check-ins. As of August 2026 the check-in service runs on five servers:
| Host | Provider | Location |
|---|---|---|
triplepat.com / triplepat.net | Hetzner | Falkenstein, Germany |
a.triplepat.com / a.triplepat.net | AWS | Frankfurt, Germany |
b.triplepat.com / b.triplepat.net | Google Cloud | Columbus, Ohio, US |
c.triplepat.com / c.triplepat.net | AWS | Northern California, US |
d.triplepat.com / d.triplepat.net | Hetzner | Helsinki, Finland |
Every host answers under both domains, so there are ten HTTPS front
doors, and every host accepts email for both checkin.triplepat.com and
checkin.triplepat.net, so there are ten mail slots. Any front door
accepts a check-in, and all of them report it.
Each layer of that spread covers a different way of failing. Five servers
cover a machine dying. Three providers cover a provider having a bad day.
Five regions in three countries on two continents cover a regional outage
or a national network incident. Two domains on two different DNS providers
(the .com zone is served by GoDaddy, the .net zone by Cloudflare) cover
a DNS provider outage, and two top-level domains cover a registrar dispute
taking one domain offline. The service status
page shows the same picture live: every
front door has to be down before a check-in has nowhere to go.
The full list of hosts is in the API documentation.