Why community fiber coops publish internet outage notes as static software status pages 2026-09-02T2231Z

A community fiber cooperative does not need another customer-relationship platform to tell a town why the internet is down. It needs a status page that still loads when the billing portal, the chat widget, and the office Wi-Fi are all unreachable. That is a software problem first: what is the smallest digital artifact that remains readable when the rest of the stack is unhappy?

The pattern that keeps working is a static status page. Volunteers compile a short markdown file, a deploy script turns it into HTML, and a content-delivery network serves the snapshot from the edge. There is no application server to reboot and no database connection to time out. If the coop’s own last-mile network is dark, members still reach the page on a phone that has switched to cellular data.

The editorial rules are stricter than the technology. Each incident note names the neighborhood, the symptom, the start time, and the next update window. “We are aware of an issue” is not a status. “Oak Street laterals lost light at 6:14 a.m.; splicing truck on site; next note by 8:00 a.m.” is a status. Members forgive delay. They do not forgive vagueness that forces them to refresh a dead router for an hour.

Automation stays humble. A probe on a nearby cloud virtual machine pings the core router and the public DNS and writes a red banner when both fail. Humans still write the paragraph. Fully generated incident copy sounds confident and is often wrong. A volunteer who walked the easement can say whether a backhoe or a blown optic is the actual cause.

History belongs on the same static site, not in a ticket system that only staff can open. A monthly archive of closed incidents teaches the board which laterals fail after freeze-thaw cycles and which cabinets overheat. That archive is also the only honest answer when a county grant asks how often residential service actually dropped. Screenshots of a Slack channel are not a record.

Security is easier when the page cannot run code. No login form, no comment box, no third-party analytics script that phones home through the same broken path members are trying to diagnose. A Content-Security-Policy that allows only the coop’s own stylesheet is enough. The page is documentation, not a web application pretending to be documentation.

Deploys should be boring. A single Git commit updates status.md, continuous integration builds the HTML, and the hosting provider atomically replaces the previous file set. If the build fails, the last good page stays live. That last-good behavior is the whole point of treating outage notes as software releases instead of CMS drafts that can render an error page at the worst moment.

Internal tools can stay richer. Technicians still use a private dashboard for optical levels, truck rolls, and member callbacks. The public internet page is a projection of that work, not a second source of truth. When those two views drift, the public page wins until someone writes a correction. Members should never see a green banner while their lights are dark.

Cost is the quiet argument that sells the board. A static site on commodity hosting is a few dollars a month. An uptime vendor with branded widgets is fine for a venture-backed SaaS company and oversized for a 900-pass coop. The money saved on the widget pays for spare splice trays. Reliability theater is not the same as reliability.

The lesson travels beyond fiber. Any small technology operator — a school district app team, a municipal sensor network, a regional software shop — can keep a public incident note that does not depend on the system being described. Write the file. Deploy the snapshot. Date the next update. When the internet comes back, the archive is already there, and nobody has to reconstruct the morning from memory and text messages.