Platform Status

Last updatedView as Markdown

Platform Status is the service behind status.linchpin.com. It monitors Linchpin’s own infrastructure, aggregates the status feeds of the hosting providers and services we depend on, and monitors roughly 114 client sites through StatusCake — all from a single Cloudflare Worker.

Uptime monitoring and status page

One Worker, every signal

Linchpin’s own services, our hosting partners’ status feeds, and 114 client sites — monitored, correlated, and published from a single Cloudflare Worker running on a one-minute cron.

github.com/repo
docs/
index.mdquickstart.mdapi.md
DocsPresskeeps one source
For readersWordPress PagesNative Gutenberg
For agents/llms.txtExact page.md routes
Reviewable pull requestWordPress edits return to GitHub

Where to start

  • Getting started — local setup, and the configuration file that drives everything.
  • Guides — external status feeds, suppression rules, webhook ingestion, notifications, and StatusCake client monitoring.
  • Reference — the public API, every uptime.config.ts field, and the Worker’s bindings and environment.
  • Architecture — how one Worker serves three layers, and how incidents are stored.

What it does

Three distinct jobs share one Worker and one D1 database.

Monitors Linchpin’s own services. HTTP, HTTPS, and TCP checks against our APIs, dashboards, and documentation, run from Cloudflare’s edge on a one-minute cron. Geo-specific checks can originate from any of ~310 cities.

Aggregates provider status. Pantheon, WP Engine, Pressable, Cloudflare, Automattic, GitHub and others publish RSS feeds and Atlassian Statuspage webhooks. Those are polled and ingested, then normalised into the same shape as our own monitors so the public page presents one coherent picture. A single provider feed can be split into several service cards, and items that do not affect us can be suppressed without losing the history.

Watches client sites. ~114 client sites are checked by StatusCake, which notifies this Worker through a single contact group. Client names and outage history stay behind Cloudflare Access — they are never published to the public status page.

Flow

How a check becomes an alert

7 relationships
Suppression is applied on read, not at ingest, so removing a rule restores the history it was hiding.

Two things worth knowing early

Suppression is applied on read. Everything a provider publishes is stored, whether or not a rule hides it. Removing a rule restores the history it was hiding, and the admin always shows the unfiltered truth. See Suppression rules.

Zero webhook deliveries does not mean zero data. Every provider is polled once a minute regardless of whether it pushes to us, and polling is where most incidents come from. The delivery table counts only pushes. See Webhooks.

Project status

This began as a fork of UptimeFlare and has since diverged substantially — a different storage backend, a different front end, an admin application, an email layer, and client-site monitoring that has no upstream equivalent. Upstream documentation no longer describes this codebase and should not be used as a reference for it.

Have a question about this page?

Linchpin assistant

Was this helpful?