Upptime

What Upptime does

Upptime turns a GitHub repository into an uptime monitor and status page. You create a repository from the Upptime template, list your endpoints in a single .upptimerc.yml file, and a set of GitHub Actions workflows does the rest. One workflow checks every endpoint, by default every five minutes. Another records response times and commits them to the repository, a third draws graphs, and a fourth builds a status website and publishes it with GitHub Pages. The repository’s README is rewritten with a live summary table.

The author built it for his own startup, wanting a monitor and status page fully under his control, and noticed that the then-new GitHub Actions could run one for free.

Checks are HTTP requests with any method, custom headers and body, a list of status codes that count as up, and a threshold above which a response counts as degraded. Rules can mark a site down when expected text or a regular expression is missing from the body. For non-HTTP services there is a plain TCP connection check and a TCP check that sends data and inspects the reply, for example to confirm a Redis server answers PING. Tokens and private URLs are kept in GitHub repository secrets, and recent versions let you list exactly which secrets Upptime may use.

Incidents and status page

When an endpoint goes down, Upptime opens a GitHub issue, assigns the people you name, and closes the issue when the endpoint recovers. Your team posts updates as issue comments, which appear on the status site as incident reports, and issues are locked so outsiders cannot comment. Planned work is announced by opening an issue labelled maintenance with start and end times; endpoints listed as expected to go down will not trigger incidents during that window.

The status site is a static progressive web app built with Svelte. It can use a custom domain and translated strings. Notifications can go to Slack, Microsoft Teams, Discord, Telegram, Zulip, Gotify, custom webhooks, email through SMTP or several sending services, and SMS through providers such as Twilio, Plivo and 46elks.

Running Upptime

There is nothing to install on a server. You need a GitHub account, workflows and Pages enabled, and a GitHub App or fine-grained access token with write access to Actions, Contents, Issues and Workflows. The documentation estimates about 3,000 Actions minutes a month in the default setup: free on public repositories, billed on private ones. A private repository can still publish a status page, but only through an authenticated API proxy you set up.

By default checks run on GitHub’s own runners. You can point workflows at self-hosted Linux runners, which the documentation suggests for more punctual schedules or to save minutes, or route individual checks through the Globalping probe network and choose a continent, country, city, network or cloud region.

Hosted version

There is no separate hosted service. Upptime runs on GitHub’s infrastructure under your own account, so its availability and limits are GitHub’s.

Limitations

Five minutes is the shortest interval, because scheduled GitHub Actions cannot run more often, and scheduled runs are not guaranteed to start on time. Check types are limited to HTTP and TCP; there are no documented DNS, database or certificate-expiry checks. Everything depends on GitHub, so a GitHub outage or a change to Actions terms affects your monitoring, and the setup assumes your team is comfortable with repositories, secrets and workflows.

Who it suits

Upptime suits open source projects, small teams and individuals who already live on GitHub and want a public status page and basic uptime alerts at no cost. If you need checks every minute or more check types, run Uptime Kuma or Gatus on a small server; for a hosted status page with multi-region checks, look at OpenStatus.