Methodology
How this log works
This is an independent status page. It runs on its own small service, records every probe in SQLite, and renders these pages on the server — so it can still answer when the main site cannot.
What is checked
Six checks run from a single vantage in Shenzhen, CN: the website, the content manifest, the API health endpoint, the guestbook API, the contact mail relay and the MCP service. Most run every 60 seconds; mail and MCP run every 120 seconds. Every probe is a real request with a timeout.
How a single check is graded
A valid 2xx response that arrives within the latency budget — 3 seconds for most checks, 5 seconds for mail — is a success. A failed check, a 5xx, or a response past that budget is degraded. Two consecutive failures become down. An HTTP 401/403/429 or a bot challenge is recorded as unknown, never as down — a blocked probe is not evidence of an outage.
How a day is graded
Days use the UTC+8 calendar. Any failed check makes that day degraded; if at least 5% of a day’s known checks are down, the day is down. If unknown checks outnumber known ones, the day is unknown. Uptime is successful checks divided by known checks. A day with no checks has no cell — never a fake 100%.
What this log cannot see
This is one vantage point, not the whole internet: a reachable probe does not prove every visitor can reach the site, and a failing probe from one network can be a routing problem rather than an outage. Unknown is not healthy. And a status page cannot report its own outage — the main site shows a local fallback when this API is unreachable.
Incidents and updates
A sustained failure opens an automatic incident, which a human can annotate but never silently deletes. Every update is appended to the timeline with its author and whether it was automatic. Nothing is edited away; corrections are new entries.
Data, feeds and badges
Everything on this page is also available as JSON, RSS and an SVG badge. The API is read-only and CORS-enabled for jonathanlye.com.