Every 15 minutes, status.dliu.com visits each dliu.com site the way a guest would (no sign-in, no cookies)
from Ireland, Virginia (US) and Tokyo, plus once an hour from inside mainland China, and decides whether each of its
functions is up, degraded or down.
Components
BrowserPeople
VisitorsRead the status page; no account
HTTPS, status.dliu.com
EdgeCloudFront
DistributionServes the page and the latest result; caches it 60 s
Routes function/docs, and the old /docs/health link
the page and result come from
PrivateAWS account
Site bucketThe pages and /data/status.json
State bucketStreaks, 90 days of history, incidents; never served
Probes (Virginia, Tokyo)The same checks from there
China (Globalping)Two probes, hourly
as a guest, to every dliu.com site
Internetdliu.com sites
11 sitesTheir pages, public endpoints and /health
One check run
1Every 15 minutesthe checker in Ireland starts
2Visit from 4 placesIreland, Virginia and Tokyo; China hourly
3Pages, APIs, /healthwhat each site's testing page lists
4Combine and judgeup, degraded or down for each function
5Publishthe status page shows the result
The checker has no sign-in and no access to the sites' data. It sees only what any visitor sees.
Four locations
Each check runs from Ireland, Virginia (US) and Tokyo, so a problem near one place doesn't look like an outage, and a
problem only one place sees still shows up. Once an hour, two home-broadband probes in mainland China (one on China
Telecom, one on China Unicom) also open each site's home page and health check, to catch a site that's blocked or
unreachable in China.
Passes everywherepass
Fails from one placedegraded, e.g. "fails from Tokyo only"
Fails from most placesfail
Up, degraded or down
Upevery check passed
Degradedslow, failing from one place, reported "warn", or failed once
Downfailed two runs in a row
A site is down when one of its essential functions is down, and degraded when any function isn't fully working (an optional one, such as Docs, being down only makes it degraded).
A failed check is tried again 2 seconds later in the same run, so one lost request doesn't count.
Availability counts degraded as available; only down time lowers it.
Private sites are checked too but not shown here.
The checks never count as visits on traffic.dliu.com.
Technical details
Part
What it is
Schedule
EventBridge rule rate(15 minutes) in eu-west-1, no retries.
Checker
Lambda (Node.js 22, arm64, 256 MB, 120 s) in eu-west-1. Runs the checks itself (Ireland), calls the probes, merges, judges, and writes the state and /data/status.json.
Probes
Lambda dliu-status-probe in us-east-1 and ap-northeast-1 (stacks StatusProbe-us, StatusProbe-jp): same code and checks, invoked synchronously, returns raw results. No permissions beyond its logs.
Requests
GET or HEAD, 10 s timeout, redirect: manual, no cookies or Authorization, user agent dliu-status-bot/1.0 (+https://status.dliu.com/docs). Four sites at a time, each site's checks in order.
China
Globalping (by jsDelivr, free, no account): once an hour, 2 probes (China Telecom, China Unicom) run each site's home-page check and /health, about 40 tests an hour, under the free 250 an hour. Its results count until the next hourly run. China fails a check only when both probes fail; slow means over 6 s (CloudFront has no servers in mainland China). If Globalping is unavailable, the last results count for one more hour, then China shows as not checked.
Combining
Per check: fail when more than half the locations that answered failed; warn when some failed, or more than half were slow; otherwise pass, with the median time. /health functions are combined the same way. A probe that doesn't answer is left out.
Definition
config/apps.json in dliu-com/status, imported from each site's /docs/health.md; the contract is HEALTH.md.
State
Private S3 bucket: failure streaks, 90 days of daily counts per site, incidents, private sites included. Kept if the stack is deleted.
Page
Static files in a private S3 bucket behind CloudFront (origin access control), /data/status.json cached 60 s, pages no-cache.
Every check
What is checked on each site right now, and the latest result. Each site's own testing page explains why.
Loading…
Cost
About $0.06 a month, well under the $1 limit, because nothing runs between checks.
~40 tests an hour, within the free 250 an hour; no account
$0
Results between regions
~0.3 GB from Virginia and Tokyo to Ireland
~$0.01
CloudFront
the probes and this page, well inside the free 10 M requests
$0
Each site's /health
at most one backend run a minute per edge (60 s cache)
< $0.02
Logs, schedule, DNS record, certificate
small
~$0
Why no CloudWatch metrics
Reading Lambda and CloudFront metrics for every site every 15 minutes would cost about $2 a month with
GetMetricData, over the limit. The checks are instead purely what a guest sees, plus each site's own /health.
Security
status.dliu.com is a guest: it can't sign in to, change or read the private data of any site, and its
page shows only whether things work.
No sign-inno cookies, tokens or passwords anywhere
Read onlyGET and HEAD; never changes anything
Least accessno AWS access to the other sites
Nothing private shownstatus only; private sites left out
What could go wrong, and what stops it
Risk
Protection
The checker is misused to change a site
It only sends GET and HEAD, without cookies or credentials, and doesn't follow redirects. A test fails the build if a check uses another method, adds headers or a body, or points at another host.
Its AWS role is misused
The checker may only read and write its own state file, write data/* on its page, and call the two probes. The probes have no permissions. Nothing can read the other sites' databases or storage.
The page leaks private details
It publishes statuses and short generic reasons only: no response bodies, no identifiers (JSON values checked by pattern are never echoed), and private sites (jh.dliu.com) are left out of the public file entirely.
Script injection on the status page
Strict Content Security Policy (scripts from this site only, no inline), every value written with textContent (a test forbids innerHTML), framing denied, HSTS.
Using status.dliu.com to flood a site
There is no way to start a check from outside: only the schedule runs them. Each site's /health is cached 60 s at CloudFront.
China probes are run by volunteers (Globalping)
They only fetch public pages anyone can see, send no cookies or credentials, and a single probe's result can't make a site look down: China needs both probes to fail, and China alone failing only marks a site degraded.
Someone hides from traffic.dliu.com by faking the checker's user agent
Accepted: they only hide their own visits, and such traffic already counts as a bot.
Technical details
Both buckets block all public access, use SSE-S3 and refuse non-TLS requests. CloudFront reads the page bucket with origin access control.
IAM: s3:GetObject/PutObject on state.json, s3:PutObject on data/*, lambda:InvokeFunction on dliu-status-probe in us-east-1 and ap-northeast-1. The stack test fails if CloudWatch, DynamoDB, CloudFormation or wildcard S3/Lambda permissions appear.
DL status