Upptime

Last reviewed Aug 26, 2026 · 881 words

Upptime can only monitor what GitHub's runners can reach, which means public URLs and nothing behind your firewall. Read that sentence twice before you get excited, because everything else about it is excellent: a free status page, downtime alerts, response-time history, and no server at all. If your goal is watching a handful of internet-facing sites (your blog, your public Nextcloud, a friend's shop) it is the cheapest credible monitor there is. If your goal is watching the Proxmox box in the cupboard, it structurally cannot help.

It is a repository, not a service

The whole product is a GitHub template repository, MIT-licensed and at about 17,100 stars. You click "Use this template", edit one YAML file, add one secret, and GitHub Actions does the rest: a scheduled workflow curls each site, commits the result and response time to the repo, opens an issue when a site fails and closes it when it recovers, and rebuilds a static status page onto GitHub Pages. The history is git history, so the "database" is commits and the audit trail is free.

# .upptimerc.yml
owner: yourname
repo: upptime
sites:
  - name: Blog
    url: https://example.com
  - name: Nextcloud
    url: https://cloud.example.com/status.php
  - name: SSH
    check: tcp-ping
    url: example.com
    port: 22
status-website:
  cname: status.example.com
  name: Example Status

The one secret is GH_PAT, a personal access token with repo scope, because the default Actions token is not allowed to trigger other workflows. Set it, push, and the first checks run within a few minutes. Alerts go out through notification secrets for Slack, Telegram, Discord, email and others; you set them in the repository settings, not in the YAML, which keeps webhooks out of a public repo.

Every 5 minutes is a ceiling, not a promise

GitHub's cron schedules run no more often than every 5 minutes, and under load they slip. Ten to fifteen minute gaps are normal at busy times, and I have seen 30. So Upptime's real detection latency is "somewhere between 5 and 30 minutes", which is fine for a personal site and unacceptable for anything with a paying customer on the other end. There is no way around it; the check interval is GitHub's, not Upptime's. Treat the response-time graphs the same way: they measure latency from wherever GitHub's runner happened to be, which is a useful trend and a meaningless absolute.

Free means public

Actions minutes are unlimited for public repositories and capped at 2,000 per month on GitHub's free plan for private ones. Upptime's default workflows fire hundreds of times a day, and my rough estimate is that a private repo with 10 sites burns through 2,000 minutes in around 2 weeks. So in practice the repo is public, which means your list of monitored URLs, their uptime history and their downtime issues are public too. For most personal setups that is harmless. For a company it is a decision to make deliberately, and the cheaper fix is to only monitor endpoints you would put on a status page anyway.

What you get is more than a ping

The status page is the part that impresses people. It shows 24-hour, 7-day, 30-day and yearly uptime per site, response-time charts, and a list of past incidents pulled from the auto-generated issues. Downtime issues are real GitHub issues, so you can comment on them with a post-mortem and the status page picks up the text. A custom domain is one cname line plus a DNS record. None of this needs a database, a container, or a server that you have to patch, which is the strongest argument for it.

Where Uptime Kuma or Gatus take over

The moment you want to monitor something on your LAN, a Docker socket, a DNS resolver, or anything at 30-second resolution, you need a monitor that runs on your network. Uptime Kuma is the usual choice for a homelab and Gatus the choice for people who want the config in git; the Gatus vs Uptime Kuma piece splits the decision. The two setups are not rivals. A self-hosted monitor cannot tell you your house lost power, and Upptime cannot see inside the house, so plenty of people run both: Uptime Kuma inside for detail, Upptime outside as the check on the checker. My broader take on this is in the homelab uptime monitoring post.

What I'd do

Set up Upptime for every public URL you own; it takes 15 minutes, costs nothing and never needs an update from you. Point it at a status endpoint rather than a home page where one exists, use tcp-ping for SSH and mail, and enable one notification channel you actually read. Then run Uptime Kuma inside the network for everything private and add your Uptime Kuma instance's public URL to Upptime's list, so the outside monitor tells you when the inside one goes dark. Do not try to make Upptime watch your LAN through a tunnel; you would be exposing internal services to solve a problem the wrong tool created.