# Statsig statuspage: a static status page fed by a git log

> The statuspage repository is a status page with no backend: a shell script curls each configured URL on an hourly schedule and commits the result to a log file that a static page reads and displays. It suits teams that want a public availability view in a few minutes, but it has no incident model, no outage duration tracking and no root cause field.

**statsig-io/statuspage** — A simple, zero-dependency, pure js/html status page based on GitHub Pages and Actions.

- Repository: https://github.com/statsig-io/statuspage
- Stars: 768 · Forks: 321
- Language: JavaScript
- License: ISC
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/statsig-io-statuspage

## A status page with no server behind it

The statuspage repository is described as a simple, zero-dependency, pure JavaScript and HTML status page based on GitHub Pages and GitHub Actions. The README is frank about its origin: the maintainers tried various status pages out there and built this as a fun little hobby project to make status pages as simple as possible.

The simplicity is structural rather than cosmetic. There is no application server, no database and no API to run. What you get is a static page served by GitHub Pages, a configuration file listing the URLs to check, and a script that checks them.

The demo is at status.statsig.com, and the repository is published by Statsig as a template, meaning the intended path is to fork it. The README even has a section pointing people who want developer-friendly feature flags and A/B experimentation to the company's main product, which tells you the status page is a side project rather than the product line.

The audience is a team that wants a public-facing availability page without buying or hosting one. That is a real need for small services, internal tools and side projects, and this is one of the shortest paths to satisfying it.

## Git as the database: curl, log, commit

The mechanism is the interesting part, and the README describes it in one paragraph.

The project uses GitHub Actions to wake up every hour and run a shell script, health-check.sh. That script runs curl on every URL in the config and appends the result of that run to a log file, and then commits it to the repository. The log is then pulled dynamically from index.html and displayed in an easily consumable fashion.

So the data path is: a scheduled workflow, a curl per configured URL, an append to a log file, a git commit, and a static page that reads the log and renders it.

Using the repository itself as the store has an appealing property for a status page: the history is the history. Every check is a commit, the timeline of availability can be reconstructed from the git log, and there is no database to back up, migrate or lose. GitHub Pages serves the same repository that the Action commits to, which means there is no publish step and no separate deployment target.

The cost is that the update granularity is the commit granularity. The page shows what the last run recorded, and the history is the commit log, so a burst of incidents is represented by a burst of commits rather than by structured events. That is a fine trade for a hobby project and a questionable one for a page that has to answer questions during an incident.

## The four setup steps from fork to live page

The README documents the setup as a numbered list, and the whole thing is small enough to reproduce in one sitting.

Step one is to fork the template repository. Step two is to update urls.cfg with the URLs you want to watch. The file is a simple key and value list, one URL per line:

```cfg
key1=https://example.com
key2=https://statsig.com
```

The keys are what you will see in the page, so they are labels rather than machine identifiers.

Step three is to edit index.html and change the title, which the README shows as a two-line change covering both the browser tab and the heading on the page:

```html
<title>My Status Page</title>
<h1>Services Status</h1>
```

Step four is to set up GitHub Pages for the repository, and the README includes a screenshot of that settings screen because the choice of branch and directory is the part people get wrong.

There is no build step, no package to install and no configuration file for the workflow. The Actions workflow that performs the hourly check is already in the repository under .github, and the health check script sits at the root next to urls.cfg, index.html, index.js and index.css, with a logs directory holding the generated output and a logo.svg for branding.

## What it explicitly does not do

The README has a section titled What does it not do (yet), and it is the most useful part of the documentation for anyone making a decision.

Three things are listed. There is no incident management, no outage duration tracking, and no updating of status root cause.

Those are the three features that separate a public status page from a piece of information. A status page that only says whether a service is up tells a customer nothing about when the problem started, whether it is over, or what went wrong. Customers and support teams want all three, and a page that cannot answer them will generate support tickets instead of reducing them.

The parenthetical (yet) in the heading is doing some work. It signals that these are gaps rather than decisions, and that a fork could add them. That is true in principle, since the log file is plain text and the page is plain HTML and JavaScript. In practice, adding incident management means inventing a data model, and a fork that invents its own diverges from the upstream template, which raises the upgrade cost of a project whose main appeal is that it is four files and a cron job.

For a team that only needs an availability indicator, the missing features are not important. For a team whose status page is part of a customer-facing incident process, they are the whole product.

## Running the check more often from your own infrastructure

The hourly schedule comes from GitHub Actions waking up, and the README notes that you can also run that script from your own infrastructure to update the status page more often.

That is the natural escape hatch. The script is a shell script that runs curl over the URLs in the configuration and appends to the log, so anything that can run a shell script and commit to the repository can drive it: a cron job on a server, a Kubernetes CronJob, a CI pipeline on another service.

The trade-off is access to the repository. Committing to the repository is what publishes the update, so a self-hosted runner needs credentials with push rights. A personal access token or a deploy key is the usual answer, and either one adds a credential to maintain and a second place where it can leak.

There is also a cost consideration that follows directly from the design. Each run performs one curl per configured URL, and the hourly schedule means 24 runs a day, so a list of ten endpoints is 240 requests a day to your own services, plus the commits. Running it more often multiplies that. For a status page that is usually acceptable, and for a service that rate limits or blocks requests from unknown agents, it is a detail worth checking first.

## Zero dependencies, ISC licensed, and no release history

The repository has no build tooling at all. The file list at the root is short: the health-check.sh script, index.html, index.js, index.css, logo.svg, urls.cfg, a logs directory, a .github directory for the workflow, plus the usual repository files.

That is what the zero-dependency description in the repository summary refers to. There is no package.json, no lock file, no framework. The page is static HTML with a script that fetches and renders the log, and the check is a shell script. There is nothing to install and nothing to keep up to date, which is a genuine advantage for a page that has to keep working when nobody is paying attention to it.

The licence is ISC, and the repository carries a LICENSE file. The README also includes the health-check workflow badge, which points at a workflow file named health-check.yml.

On activity, the repository is not archived and the last push was on 2026-09-29, but it publishes no GitHub releases. That is consistent with a template repository, where the useful artefact is the main branch rather than a versioned distribution, and it means you should fork the current main branch rather than look for a tagged release to pin.

The README invites pull requests with new ideas, which is a reasonable posture for a template: the upstream value comes from other people's forks being small and mergeable, which is a good reason to keep the file count low.

## Conclusion

Use the statuspage template when you want a public availability page for a handful of endpoints within an afternoon, and you are happy for the history to live as commits in a git repository. Do not use it once you need incident management, outage duration tracking or a root cause field, because the README lists all three as things it does not do, and the hourly cadence plus a single log file is not a substitute for those. Before you fork it, decide how many URLs you need to check, since each one costs a curl on every run, and check that your own infrastructure can run health-check.sh if you want a shorter interval than the hourly GitHub Actions schedule.

## FAQ

### How do I set up the Statsig status page template?

Fork the template repository, update urls.cfg with the URLs to check, change the title in index.html, and enable GitHub Pages for the repository. There is no build step and no package to install.

### How does the status page know whether a service is up?

GitHub Actions wakes up every hour and runs health-check.sh, which runs curl on every URL in urls.cfg, appends the result to a log file and commits it to the repository. The log is then pulled dynamically by index.html and displayed.

### What can this status page not do?

The README lists three gaps: incident management, outage duration tracking and updating status root cause. It also notes that you can run health-check.sh from your own infrastructure if you want to update the page more often than the hourly schedule.

### Does the status page need any dependencies or a backend?

No. The repository summary describes it as a simple, zero-dependency, pure JavaScript and HTML status page based on GitHub Pages and GitHub Actions, and the repository contains only the shell script, the static page files, a config file and a logs directory.

## Sources

- [Issues](https://github.com/statsig-io/statuspage/issues)
- [License: ISC](https://github.com/statsig-io/statuspage/blob/main/LICENSE)
- [README](https://github.com/statsig-io/statuspage/blob/main/README.md)
- [statsig-io/statuspage on GitHub](https://github.com/statsig-io/statuspage)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/statsig-io-statuspage