Upptime

Build from a repository

Start from the official upptime/upptime GitHub template and include all branches. In .upptimerc.yml, set the repository owner and name, then list each endpoint with a readable name and URL. For example:

sites:
  - name: API
    url: https://api.example.com

Enable the repository's Upptime workflows in the Actions tab. If you want a public status website, enable GitHub Pages for the generated gh-pages branch. The upstream instructions also describe repository secrets and tokens used by workflows; keep credentials in GitHub's secret store rather than in the configuration file.

Checks become an incident history

The scheduled workflow visits endpoints at intervals no shorter than five minutes. Response times are written to Git history once per day, which supports longer trend charts without a separate metrics database. When a monitored endpoint is down, Upptime can open a GitHub Issue for incident notes and close it when service returns. Its static status page combines current state, incident history, and response-time charts.

This arrangement suits maintainers who already work in GitHub and want monitoring configuration and history alongside their code. It is not an application-performance monitor: it checks configured endpoints and shows availability context, but engineers still investigate the underlying service and deploy a fix.

Plan around GitHub's limits

Upptime is MIT-licensed and has no separate subscription. GitHub Actions minutes and GitHub Pages are still part of the operating cost: the documentation notes that private repositories may incur charges for the build minutes Upptime uses. Publishing a status site from a private repository also requires an authenticated API proxy. The five-minute minimum interval is a poor fit when a team needs near-immediate alerting.