cState

Open-source static status pages, honestly reviewed. No marketing fluff, just what you get when you deploy it.

TL;DR

• What it is: A JAMStack static status page built on Hugo (Go). Not a monitoring tool — an incident communication hub where you manually post updates and let your users know what’s happening [3][README].
• Who it’s for: Indie hackers, small SaaS teams, and open-source projects that want a professional-looking status page without paying Atlassian $29–$199/mo for Statuspage. Also anyone who wants to host a status page on a CDN with zero backend to maintain [README][website].
• Cost savings: Statuspage starts at $29/mo; Hund and paid alternatives run $20–$100+/mo [5]. cState itself is MIT and free. Hosting on Netlify’s free tier is $0. Total monthly cost: literally nothing for a typical small team.
• Key strength: Genuinely fast (Go/Hugo builds thousands of entries in seconds), no server needed, no database to protect, and it works on Internet Explorer 8 [README][3]. The architecture means it stays up even when your main infrastructure is on fire — because it’s just static files on a CDN.
• Key weakness: cState cannot monitor anything automatically. It will not ping your servers, alert you to downtime, or update itself. Someone has to write the incident post, every time. That is a deliberate architectural choice, not an oversight [README].

---

What is cState

cState is a static status page generator. You write incident posts in Markdown, run Hugo to build the site, and push the output to Netlify, Cloudflare Pages, GitHub Pages, or any CDN. Users visiting your status page see a clean, fast page listing current and historical incidents, which systems are affected, and how long resolution took [README][website].

The GitHub description is honest about the trade-off: “Please note that with all that cState can do, it cannot do automatic monitoring out of the box. You can think of the cState status page as an informational hub.” [README] This is a meaningful distinction. Statuspage.io, Instatus, Uptime.com — they’re monitoring platforms that happen to have a public-facing page. cState is the public-facing page, nothing more. You bring your own monitoring.

What justifies choosing a tool with that constraint? Two things. First, the architecture is the reliability story. A static page on a CDN doesn’t go down when your database server crashes. Second, most of the time, services are up — so the status page doesn’t need to be updated constantly, and a static, pre-built page is a perfect fit for something that changes infrequently [website]. The project has been in development since 2017, is trusted by Chocolatey, sr.ht, and the Tor project (listed as users on the official site), and sits at 2,841 GitHub stars [README][website].

The tech stack: Hugo (Go-based static site generator) + minimal HTML/CSS/JS. No framework bloat. The site loads fast on IE8 — not because IE8 is a target audience, but because it’s a useful proxy for “works everywhere, no JavaScript required for core content” [3][README].

---

Why people choose it

The case for cState is mostly made by the alternatives being expensive or architecturally wrong.

The SaaS alternatives cost real money. Atlassian Statuspage (the incumbent) starts at $29/mo for small teams and scales to $199/mo for larger ones. Instatus has a free tier but paid plans for custom domains and team features. Hund charges for advanced features [5]. For an indie hacker or a small open-source project, that’s $350–$2,400/year for a page that mostly says “All systems operational.”

The JAMStack angle genuinely matters for reliability. The pixeljets.com post [1] makes the case for self-hosting at length: full control over data and infrastructure, no vendor pricing changes, no surprise deprecations. With cState specifically, you get something stronger — there is no vendor to go down. Your status page is static files. Even if Netlify has a partial outage, CDN edge nodes keep serving your cached content. There’s a reason incident response teams have historically separated their status infrastructure from their main infrastructure.

Open-source projects need free options. The AlternativeTo page [5] shows the landscape: most of the recommended alternatives are paid SaaS. For an open-source project like sr.ht or Chocolatey — both real cState users — paying $30/mo to Atlassian for a status page is a hard sell. cState on Netlify’s free tier is $0 with no catch.

The editing experience is usable for non-developers. Netlify CMS ships pre-configured with cState. You log into a web UI, write the incident, hit publish, and Netlify runs the Hugo build and deploys. Non-technical team members can post updates without touching the command line [README][3]. This is a genuinely important feature — your status page is most critical when things are already on fire, and “engineers only” update flows are a liability at 3am.

---

Features

From the README and official documentation:

Core status page:

• Incident posts in Markdown with linked systems/categories [README][3]
• Uptime statistics — shows how long incidents took to resolve [README][website]
• Historical incident archive, sorted and browsable [README]
• Tag-like system for grouping incidents by service [3]
• Dark mode (auto, based on system preference) — added in v4 [3][README]
• Multi-language support: English, German, French, Italian, Lithuanian, Macedonian, Dutch, Portuguese, Turkish, Tagalog [README][website]

Integrations and data access:

• Read-only JSON API [README][3]
• RSS/Atom feeds, including per-tag feeds [README][3]
• Badges from shields.io — embed current status in your GitHub README or docs [README]
• HTML embed widget (cState html-embed, v2+) — drop a dot indicator or alert on any page [README]

Publishing and deployment:

• Netlify (recommended, with CMS pre-configured) [README][website]
• Cloudflare Pages, Vercel, GitHub Pages, GitLab Pages [website pricing]
• Docker [website pricing]
• Any CDN or static host

Editing:

• Netlify CMS for no-code web UI updates [README][3]
• Forestry CMS as an alternative [README]
• Command-line Markdown for developers who prefer it [README]

Customization:

• All config from one config.yml file [3][README]
• Custom colors, HTML, views [3]
• Informational/about pages (not just incident posts) [3]
• Full Hugo theme inheritance — extend or override any template [README]

What it cannot do (from the README, explicitly): automatic monitoring, real-time uptime checks, email/Slack/webhook alerts on detected downtime. You have to integrate a separate monitoring tool (UptimeRobot, Prometheus, Zabbix, whatever) and then manually or via webhook create incidents in cState [README].

---

Pricing: SaaS vs self-hosted math

cState itself: MIT license, $0 [README].

Hosting options:

• Netlify free tier: $0, includes HTTPS, CDN, custom domain [website]
• Cloudflare Pages free tier: $0
• GitHub Pages: $0
• Self-hosted static files on a $4–6/mo VPS: $4–6/mo (mostly overkill, a CDN is better)

What you’re replacing:

Option	Monthly cost	Notes
Atlassian Statuspage	$29–$199/mo	Most mature, most expensive
Instatus paid	$20+/mo	Has free tier with limits
Hund	Paid	Advanced features, proprietary [5]
Pingdom Status Pages	Bundled with monitoring plans	[5]
cState + Netlify free	$0	No monitoring included

For a solo founder or a 2–5 person team that already has a monitoring setup (UptimeRobot free tier, Grafana alerts, whatever), cState replaces the entire status page line item. Over a year, that’s $240–$2,400 saved versus paid alternatives.

The honest caveat: if you need automatic monitoring, email subscriber notifications on incidents, or a managed SLA around the status page infrastructure itself, cState doesn’t cover that. You’d either pay for a full-stack alternative or stitch together cState + a separate monitoring service.

---

Deployment reality check

The Netlify path is genuinely simple [README][3]:

1. Click the “Deploy to Netlify” button on the cState site
2. Netlify clones the example repo to your GitHub account and deploys it
3. Set HUGO_VERSION=0.48 (or later) as a build environment variable
4. Connect a custom domain in Netlify’s UI
5. Enable Netlify CMS with a few more clicks

Realistic time estimate: 20–40 minutes for someone who has used Netlify before. 1–2 hours for someone setting up Netlify for the first time including domain DNS propagation.

Non-Netlify paths require more manual work. For GitHub Pages or Cloudflare Pages, you set up the Hugo build in a CI workflow (GitHub Actions, Cloudflare’s build config) and configure the publish directory. Still not hard, but it’s a few more config files to write [website pricing page][3].

Updating cState itself is done via Git submodule — cState acts as a Hugo theme. The getting-started guide [3] includes the specific git submodule commands. Not difficult, but it’s Git plumbing that can confuse people who haven’t used submodules before.

Posting an incident has two paths:

• Netlify CMS: log into /admin, fill a web form, click Publish. Build triggers automatically. Non-technical.
• Command line: create a Markdown file in the right directory, git commit, git push. Netlify picks it up and rebuilds.

What can go wrong:

• Hugo version pinning matters. The HUGO_VERSION env var must be set explicitly; the default Netlify Hugo version may be too old for cState [3][README].
• Git submodule confusion: people who git clone the repo without --recursive won’t have the theme files and will get an empty site. The README notes this but it’s a classic git footgun.
• Netlify CMS authentication requires Netlify Identity or GitHub OAuth to be wired up — one more setup step that’s not obvious from the initial deploy [3].

The project has been stable since 2017. The creator notes in the pricing page that cState was “started by a 16-year-old student from Lithuania” and is primarily funded by GitHub Sponsors. This is a one-person project, not a company. There’s no enterprise support contract available and no SLA. That’s fine for most uses — the software is MIT, the hosting is CDN-based, and there’s nothing to break at runtime — but it’s worth knowing for anyone making an organizational commitment to it.

---

Pros and cons

Pros

• $0 total cost for a typical use case. MIT software + Netlify free tier = no monthly bill for your status page [README][website].
• Architecturally reliable. Static files on a CDN stay up when your backend doesn’t. Separation of status infrastructure from main infrastructure is the right call [website][1].
• Fast. Hugo builds thousands of pages in seconds. The output is minimal HTML/CSS — no framework, no client-side rendering [README][3].
• Extreme browser compatibility. Works on IE8. More importantly, works without JavaScript for core content [README][3]. Users on degraded connections during an incident can still read your updates.
• No-code editing via Netlify CMS. Non-technical team members can post incidents without touching the command line [README][3].
• Data portability. Your incidents are Markdown files in a Git repo. Export is just git clone [1][README].
• Read-only API and RSS. Integrate with other tools or let users subscribe to updates without email [README][3].
• 10+ languages built in [README][website].
• Genuinely free for open-source projects and indie hackers — no gotchas, no “free tier” that quietly expires [website].

Cons

• No automatic monitoring. This is the biggest limitation. cState will not tell you when something goes down. You need a separate tool for that [README]. Every status update is manual.
• No subscriber notifications. Users can follow the RSS feed, but there’s no built-in “email me when an incident is posted” feature. Paid alternatives like Instatus and Statuspage include this [5].
• One-person project. No company behind it, no enterprise support, no roadmap guarantees [website pricing]. The project appears largely in maintenance mode — the GitHub shows the last major version as v5, with the html-embed as the most recent notable addition [README].
• Git submodule for updates. Keeping cState up to date requires understanding Git submodules. Not complex, but not obvious for non-developers [3][README].
• CMS setup has friction. Netlify CMS requires Netlify Identity or GitHub OAuth — it’s not zero-config after the initial deploy [3].
• No incident webhooks out of the box. If you want to fire a Slack message when you post an incident, you build that integration yourself [README].
• No multi-user access control. Anyone with commit access to the repo can post incidents. Fine for small teams, inadequate for larger organizations [README].

---

Who should use this / who shouldn’t

Use cState if:

• You’re an indie hacker or small SaaS team paying $30–$200/mo for Statuspage and looking for a $0 replacement.
• You’re maintaining an open-source project that needs a status page and has no budget for SaaS.
• You already have uptime monitoring (UptimeRobot, Grafana, Zabbix) and just need the public communication layer.
• You want your status page to survive independently of your main infrastructure.
• You want full ownership of your incident data in plain Markdown files.

Skip it (pick Instatus or a hosted option) if:

• You need automatic email/SMS/Slack notifications to subscribers when you post incidents.
• You want real-time monitoring built into the same platform.
• You need team permission controls (only certain people can post incidents).
• You want a managed solution with guaranteed uptime SLA on the status page itself.

Skip it (pick Kener or OpenStatus) if:

• You want an open-source option with more active development and more modern features like on-call management [5].
• You need automatic uptime checks alongside the status page in one self-hosted package.

Skip it (stay on Statuspage) if:

• You need subscriber email notifications at scale.
• Your compliance team requires audit logs of who posted what incident when.
• You need to integrate with PagerDuty, OpsGenie, or other incident management tools natively.

---

Alternatives worth considering

From the AlternativeTo page [5] and the broader self-hosted landscape:

• Kener — Open-source (MIT), Node.js, actively developed, has a slicker modern UI. Includes monitoring integration and better incident workflows. More feature-complete than cState, but requires a running Node.js server [5].
• OpenStatus — Open-source (AGPL-3.0), includes on-call management, available as self-hosted or cloud. More aligned with full-stack monitoring [5].
• Cachet — One of the older open-source status page options, PHP-based [5]. Less actively maintained than cState, needs a running server.
• Instatus — Freemium SaaS. Free tier available but paid for subscriber notifications and custom domains. Actively developed and has more features than cState [5].
• Statuspage (Atlassian) — The mature incumbent. Full monitoring integrations, subscriber emails, team controls. $29–$199/mo [5]. The thing most people are trying to escape.
• Hund — Paid SaaS with REST API, native monitoring, semantic statuses [5]. Reasonable option if you need something managed with more depth.

The realistic shortlist for a non-technical founder: cState vs Kener vs Instatus free tier. Pick cState if $0 and maximum simplicity matter. Pick Kener if you want a modern UI and automatic monitoring checks in one tool. Pick Instatus free tier if you want subscriber notifications without a server to maintain.

---

Bottom line

cState does one thing: gives your users a place to read about current and past incidents, served from a CDN that won’t go down when your backend does. For that specific job, it’s hard to beat at $0/month with an MIT license. The limitations are real — no automatic monitoring, no subscriber notifications, one-person project in maintenance mode — but they’re also clearly documented in the project’s own README, which is a good sign. This is a tool that knows what it is.

If you’re paying Atlassian $29/mo for Statuspage and you already have a separate monitoring setup, the swap to cState is probably a 2-hour afternoon project that eliminates a recurring bill entirely. If you’re starting from scratch and want monitoring + status page in one place, look at Kener or OpenStatus instead. And if the whole deployment question is the blocker, upready.dev handles exactly this kind of setup for clients.

---

Sources

1. Pixeljets — “Self-hosted is awesome” — https://pixeljets.com/blog/self-hosted-is-awesome/
2. Reddit r/selfhosted — “Should I self-host code-server?” — https://www.reddit.com/r/selfhosted/comments/19577lf/should_i_selfhost_codeserver/
3. leviwheatcroft.github.io — cState awesome-selfhosted listing — https://leviwheatcroft.github.io/selfhosted-awesome-unlist/cstate.html
4. open-source.world — awesome-selfhosted HTML index — https://open-source.world/github.com__awesome-selfhosted__awesome-selfhosted-html/
5. AlternativeTo — “cState Alternatives: Top 12 Uptime Monitor Services” — https://alternativeto.net/software/cstate/

Primary sources:

• GitHub repository and README: https://github.com/cstate/cstate (2,841 stars, MIT license)
• Official website: https://cstate.netlify.app/
• Pricing page: https://cstate.netlify.app/pricing/