Checking in from anywhere

How do you know your alerting works? A quiet pager can mean everything is fine or that your alerting isn’t working any more. A check-in timer removes the doubt, so a quiet pager means what you want it to mean.

Our eventual goal is that you configure your monitoring to fire a synthetic alert on a schedule, with a Triple Pat timer as the alert’s notification target. Each delivered alert becomes a check-in, a completed fire drill for your whole alert pipeline. Each timer has a configurable interval. If a timer goes longer than that without a check-in, Triple Pat notifies you that your alerting has a problem, which is the one thing you should not rely on your alerting system to tell you about.

In the first tutorial you sent a check-in to a real timer with one curl command. In this one you will learn the rest of the check-in service: how to read a timer’s state without touching it, how the same timer answers at ten URLs spread across servers on different domains, cloud providers, countries, continents, and TLDs. We also show how to check in with an email, because a check-in has to be sendable by whatever your alert pipeline can deliver.

To do this tutorial, all you need is a terminal with curl installed. Throughout it, curl plays the role of your alerting system, sending the requests that a real monitoring pipeline would send.

The public timers

Every timer is named by a random UUID, and the UUID works like an API key: it is far too random to guess, and knowing it is what authorizes check-ins. There is no separate account or password to manage.

For learning and testing, we operate a few public timers whose UUIDs are deliberately disclosed. In the spirit of using thoroughly disclosed secrets, they are all the well-formed UUIDs that appear in Wikipedia’s article on UUIDs. This tutorial uses the example UUID from RFC 9562, the standard that specifies UUIDs:

f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Because anyone can use this UUID, anyone might be using it at the same time you go through this tutorial. If you install the Triple Pat app, you can get your own UUIDs that nobody knows about but you.

Read the timer

Before checking in, look at the timer’s state:

curl https://triplepat.com/api/v1/getlastcheckin/f81d4fae-7dec-11d0-a765-00a0c91e6bf6

The service replies:

{
  "lastCheckinTime": "2026-08-16T12:43:34Z",
  "uuid": "f81d4fae-7dec-11d0-a765-00a0c91e6bf6"
}

lastCheckinTime is the last time anyone checked in. A timestamp with the sentinel value of 1970-01-01T00:00:00Z means no one ever has.

Reading is safe: getlastcheckin never counts as a check-in. It is also how the Triple Pat app monitors timers.

Check in

Now update the timer:

curl https://triplepat.com/api/v1/checkin/f81d4fae-7dec-11d0-a765-00a0c91e6bf6

The reply has the same shape, but lastCheckinTime is now the moment your request arrived. Run the getlastcheckin command from the previous step again and you will see the same timestamp, or a newer one if another reader has checked in since. Either way, your check-in was recorded.

That is the entire integration surface: the URL is all you need to know. GET and POST both work, so everything from a browser address bar to a cron job to a PagerDuty alert can check in. In fact, since a check-in is just a request, this link performs one; click it and your browser shows the timer’s new state.

Cross servers and TLDs

You have now checked in through one URL. Your fire drills are only as reliable as their delivery path, so that URL must not be a single point of failure. It is not: the check-in service runs on five servers. Every server accepts check-ins, and every server reports the same state no matter where a check-in arrived. The server you have been using answers at triplepat.com and triplepat.net, and its four mirrors answer at a through d on both domains, for ten URLs in all. Let’s verify that a check-in through one front door is visible through another. Check in through a mirror on the .net domain:

curl https://c.triplepat.net/api/v1/checkin/f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Then read the timer back through a different mirror on the .com domain:

curl https://a.triplepat.com/api/v1/getlastcheckin/f81d4fae-7dec-11d0-a765-00a0c91e6bf6

The timestamp matches, or is newer if someone else has checked in between your two commands. Whatever you see, every front door reports the same state. Ten front doors, one timer.

This redundancy is the point of the design. The five servers run in three cloud providers across five cloud failure domains, in three countries on two continents, and each answers under multiple names because DNS and DNS providers fail in their own ways. No single server failure, provider outage, DNS problem, national network incident, or even a registrar dispute taking a domain offline can silence your check-ins. The full list of hosts is in the API documentation, and the reasoning behind the design is in Design of the checkin service.

Check in by email

Ten URLs protect a check-in against server and DNS failures, but your alerting system may lose HTTP entirely — an outbound firewall, a broken proxy, a network that only passes mail. For that case, a check-in can travel as an email. The UUID is the address. Send an email (subject and body are ignored) to:

f81d4fae-7dec-11d0-a765-00a0c91e6bf6@checkin.triplepat.com

or, on the other TLD:

f81d4fae-7dec-11d0-a765-00a0c91e6bf6@checkin.triplepat.net

Mail delivery is not instant: allow a minute or two. Re-run the getlastcheckin command until you see the timestamp move — when it does, your email was the check-in.

The mail path has the same redundancy as the HTTP path. To prevent bad behavior, you can’t check in to multiple UUIDs using a single email. Addressing one email to the same UUID at both domains is fine, though. The two addresses name one timer, so the email counts as one check-in.

If something goes wrong

A mistyped UUID returns a 404. To discourage guessing UUIDs, the service answers that client more and more slowly for a while after a 404. If your requests suddenly seem sluggish, check the UUID, wait a few minutes, and try again.

What you now know

• A timer is a UUID and a last-check-in time; the UUID works like an API key — knowing it is what authorizes check-ins.
• getlastcheckin reads without touching; checkin updates to now. GET or POST, either works.
• Ten HTTP front doors — five servers, each named on both domains — lead to the same timer; any front door accepts a check-in, and all of them report it.
• Two mail slots, @checkin.triplepat.com and @checkin.triplepat.net, accept a check-in as an email addressed to the UUID.

Next steps

• Wire a timer’s URL into your monitoring as a synthetic alert’s notification target. That turns every scheduled alert into a real fire drill.
• Install the phone app to create a timer of your own, with a private UUID, a configurable interval, and alerts.
• Try the alarm: create a timer with a short interval, check in once, then stop — and watch who worries.
• Put a check-in on a schedule: check in from a cron job.
• Look up the details in the check-in API reference and the full API documentation.