Cstate

Last reviewed Sep 13, 2026 · 850 words

A status page that runs on the infrastructure it reports on is a status page that goes dark exactly when people look at it. cState solves that by not running at all: it is a Hugo theme that compiles a folder of Markdown incidents into plain HTML, and that HTML sits on Netlify, GitHub Pages, Cloudflare Pages or any dumb web server you want, for $0 a month and about 32 MB of RAM if you self-host the files. The trade is manual: nothing checks your services, and nothing writes incidents for you.

Separate fate is the whole reason to use it

Uptime Kuma, Gatus and their peers can render a public status page, but that page is served by the same process that does the checking, usually on the same box or the same cluster as the services it watches. A power cut, a full disk or a broken reverse proxy takes the status page with everything else. cState's output is static files on someone else's edge, so the only thing that can take it down is the host you chose, and picking a big one makes that risk very close to zero.

That is why the people who actually run cState are small SaaS operators, agencies with a handful of clients, and homelabbers who want a page they can point family at when Jellyfin is down. It fits the same slot as the hosted Statuspage product, and the Statuspage alternatives list is where it usually surfaces.

Incidents are Markdown files with five fields

Systems are declared once in config.yml. Each incident is a file under content/issues/:

---
title: Storage array rebuild slowing media playback
date: 2026-09-12T08:30:00Z
resolved: true
resolvedWhen: 2026-09-12T14:10:00Z
severity: disrupted
affected:
  - Jellyfin
  - Nextcloud
section: issue
---

08:30 UTC: a failed disk triggered a rebuild. Playback is buffering.
14:10 UTC: rebuild complete, performance back to normal.

Severity is down, disrupted or notice, and the affected list must match system names from the config. An unresolved incident turns the matching systems yellow or red on the front page; flipping resolved and adding resolvedWhen moves it into the history. Updates go in the body in reverse chronological order. The cState documentation covers the remaining options such as scheduled maintenance and languages, and the config file itself is commented well enough that most people never open the wiki.

Because incidents are files, your status history is a git log, which is more honest than any hosted product's editable timeline.

Deploying: git push, or copy a folder

Fork the example site, run hugo and you get a public/ directory. Three ways to serve it, in order of how little you have to run:

Netlify or Cloudflare Pages build from the repository on every push and there is a one-click Netlify deploy button in the README; this is what the catalogue's "one-click" deployment tag refers to. GitHub Pages with a small Actions workflow that runs Hugo does the same at zero cost. Or run hugo yourself and copy public/ to any web server, which is the right choice when the page must stay inside a private network.

Whichever you pick, put the page on a different provider from your main stack, and ideally a different DNS provider or at least a record with a short TTL, or you have recreated the shared-fate problem one layer up.

Pair it with a checker; do not confuse it for one

cState has no checks, no alerting and no automatic incident creation, which is the catalogue's second con and the main reason people move on from it. The working pattern is two tools: something that watches and pages you, and cState as the curated, human-written public face. Uptime Kuma is the biggest project for the watching half and the safer pick if you want a single tool that also serves a status page; Gatus is the config-file alternative that fits a git-driven workflow better. The status pages roundup puts all three side by side.

For editing from a phone during an outage, cState supports Decap CMS (the project formerly called Netlify CMS), which gives a small web form that commits the incident file for you. Without it, you write an incident by pushing a commit, which is fine from a laptop and irritating at 3 a.m.

What I'd do

Fork cState, host it on Cloudflare Pages or Netlify under a subdomain on a different DNS provider from your main stack, and wire Decap CMS so incidents can be posted from a phone. Run Uptime Kuma on the homelab to do the actual watching and alerting. Write an incident for anything that lasts longer than 15 minutes, resolve it with the real timestamps, and leave the history public. If you would rather have one tool and can live with the status page sharing fate with your services, use Uptime Kuma's page and skip cState.