Uptime monitoring and a status page, run entirely on GitHub.

GitHup is a free, open-source GitHub Action. It checks your services every 5 minutes, keeps the history in your repo, opens an Issue when something goes down and publishes a status page to GitHub Pages.

See the live demo Get started

No servers. No dependencies. MIT licensed. uses: StuxGroup/GitHup@v1

Features

Everything a status page needs, nothing it doesn't.

GitHup uses the parts of GitHub you already have (Actions, git, Issues and Pages) and adds nothing you have to run yourself.

Checks every 5 minutes

HTTP probes with retries, expected status codes, timeouts, custom headers and secrets, and a response-time threshold for a degraded state.

Your data, in your repo

Every check is stored as compact JSON in git: one file per monitor per month, plus a summary with uptime for 24 h, 7 d, 30 d, 90 d and all time.

Incidents as Issues

When a monitor goes down, GitHup opens an Issue. When it recovers, it comments with the downtime and closes it. Your own Issues can announce maintenance.

A fast status page

90-day history bars, uptime figures, a response-time sparkline and incidents, in light and dark themes, published to GitHub Pages. No external JS or CSS.

No servers, no bill

A composite GitHub Action running Python standard-library scripts. Nothing to host, nothing to install, and nothing to vendor.

A README badge table

Optionally keep a live status table in your README between two markers, so your repo front page shows the state of every monitor.

How it works

Four steps, all inside your repository.

Check
A scheduled workflow probes each monitor, retrying before it calls anything down.
Store
Results are committed to your repo as JSON by github-actions[bot].
Alert
An outage opens an Issue, so you get GitHub's notifications for free. Recovery closes it.
Publish
The status page is rebuilt when anything changes and pushed to GitHub Pages.

Quick start

Up and monitoring in five minutes.

Create a repository for your status page (public is simplest), then:

1. Describe your monitors

Add .githup.yml at the root of the repo. Unknown keys are errors, so typos never pass silently.

.githup.yml

site:
  name: Example Status
  cname: status.example.com
  accent: "#3ba7ff"

monitors:
  - name: Website
    url: https://example.com
  - name: API
    url: https://api.example.com/health
    expected: [200]
    max_response_time: 1000

2. Add the workflow

Copy templates/githup.yml to .github/workflows/. It checks every 5 minutes and rebuilds the page hourly and whenever a status changes.

.github/workflows/githup.yml

# in .github/workflows/githup.yml (full file in templates/githup.yml)
on:
  schedule:
    - cron: "*/5 * * * *"
permissions:
  contents: write
  issues: write
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: StuxGroup/GitHup@v1
        with:
          mode: check

3. Turn on Pages

Run the workflow once from the Actions tab. It creates the gh-pages branch; then set Settings → Pages to deploy from gh-pages.

That's it. GitHup never changes your Pages settings, and everything it does is an ordinary commit or Issue you can read. The README covers every option, from secrets in headers to deploying with Actions.

This site is monitored by GitHup.

The demo is a real GitHup status page, built by the action from this website's own repository. It checks Stux.Group services every 5 minutes, and one monitor is down on purpose so you can see an outage.

Open the live demo View on GitHub