The site that goes down, on purpose, on schedule. Point your uptime monitor here and verify it actually catches outages: detection delay, alerting, recovery, all of it.
Every endpoint's state is a pure function of the UTC clock, published in advance. Compare what your monitor reported against ground truth: /schedule.json ยท /now
| endpoint | state | flips | behavior |
|---|---|---|---|
| /outage/hourly | up | in 40m 53s | HTTP 503 for the first 15 minutes of every hour (UTC). Sized so 5-minute-interval monitors alert and recover every cycle. |
| /outage/twenty | up | in 0m 53s | HTTP 503 for the first 5 minutes of every 20-minute cycle (:00, :20, :40 UTC). Sized for 1-minute-interval monitors. |
| /flappy | down | in 0m 53s | Two minutes up, two minutes down, forever (15 outages/hour). Exercises flap handling and alert suppression. |
| /keyword | up | in 10m 53s | Always HTTP 200. The body contains DOWNABLE_KEYWORD_OK except minutes 30-44 of every hour (UTC), when it is replaced by DOWNABLE_KEYWORD_GONE. Tests content/keyword checks without any real downtime. |
| /timeout | up | in 25m 53s | Instant HTTP 200 except minutes 45-59 of every hour (UTC), when the response stalls past typical monitor timeouts before completing. |
/status/{code} returns any HTTP status 200–599, immediately./redirect/{hops} serves a chain of up to 20 redirects, then 200. Find your monitor's follow limit./redirect/loop redirects to itself forever./health is always 200. Monitor this to tell real downable outages from scheduled ones.