# Upptime: a GitHub Actions uptime monitor with a git-backed history > Upptime turns GitHub Actions, Issues and Pages into an uptime monitor and status page. It suits small teams already on GitHub who want the checks, the incident log and the site in one repository. **upptime/upptime** — GitHub Actions uptime monitor & status page by @AnandChowdhary. Upptime** ( is the open-source uptime monitor and status page, powered entirely by GitHub Actions, Issues, and Pages, made with by Anand Chowdhary. - Repository: https://github.com/upptime/upptime - Website: https://upptime.js.org - Stars: 17,167 · Forks: 1,040 - Language: Markdown - License: MIT - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/upptime-upptime ## The problem Upptime solves, and who it is for The README describes the origin directly: the author needed a monitor and status page for a startup that was affordable, flexible and under his own control, and found existing services expensive, rigid or closed-source. Upptime is the answer he built on GitHub Actions, which had just launched at the time. The target user is a developer or small team already living in GitHub who does not want another account, another bill or another dashboard to check. The design decision that follows from that is that there is no server. The README states there is no external server or subscription needed, and that all configuration lives in a single file. If you delete the repository, the data is gone. That is a real property, not marketing: the monitor, the incident record and the status page all live in one git repository, and the audit trail is the commit log. ## How the checks, issues and status page fit together The mechanism is a set of scheduled workflows. According to the README, GitHub Actions is used as the uptime monitor, and every five minutes a workflow visits your website to make sure it is up. Response time data is recorded and committed to git, which is what makes long-term trend charts possible. When downtime is detected, GitHub Issues are opened and closed automatically. The status page is built with Svelte and hosted via GitHub Pages. The repository layout matches that description. The top level contains .github/ for the workflows, .upptimerc.yml for configuration, history/ for the per-endpoint YAML records, graphs/ for the generated charts, api/ for the data the site reads, and assets/ for static files. The README's own status table shows one history file per monitored URL, for example history/google.yml, with a response time and an uptime percentage attached to each entry. The interesting part is the storage choice. Committing every check to git gives you a versioned, inspectable record with no database, but it also means the repository grows with every run, and the history is only as good as the workflow that writes it. ## Installing Upptime and running a first check Upptime is distributed as a GitHub template repository rather than a package you install locally. The README points to https://upptime.js.org for setup instructions, and the repository itself is the thing you copy. Once you have created your repository from the template, the configuration lives in .upptimerc.yml, which the README describes as the single configuration file. The README does not reproduce the contents of that file, so open the generated .upptimerc.yml in your own copy and edit the entries there. The status table in the README shows the shape of an entry: a site name and a URL, one per monitored endpoint, such as Google at https://www.google.com and Wikipedia at https://en.wikipedia.org. The scheduled workflows are already present under .github/workflows/ after the template is created. Uptime checks run on the schedule described in the README, every five minutes, and the results appear as commits to the history/ directory. If you want to trigger a run without waiting, GitHub's Actions tab lets you dispatch a workflow manually, which is the fastest way to confirm your configuration is valid. After the first runs, look at two places. The history/ directory should contain one YAML file per site, matching the names in your configuration. The status page, served through GitHub Pages, should show the same sites with a status and a response time. If history/ stays empty, the workflow is not running or the configuration file is not being read. ## Where Upptime stops being the right tool The five-minute interval is the first limit. The README states that checks run as often as every five minutes, which is fine for a marketing site and too slow for anything with a tight error budget. A service that fails and recovers inside one interval can pass unnoticed. The second limit is the dependency on GitHub itself. The monitor, the incident tracker and the status page are all GitHub services. If GitHub Actions is degraded or Pages is unavailable, your status page is down at exactly the moment you would want to point people at it. The README does not document a fallback for that case, and there is no external server to fail over to by design. The third is the data model. Because results are committed to git, the repository accumulates history on every run. That is the feature, but it also means retention is a repository-management problem rather than a setting. The README does not document a retention policy or a rollback procedure for a bad run, so plan for that before you point the monitor at production. ## Upptime compared with a hosted monitor The obvious alternative is a hosted uptime service, which checks your endpoints from its own infrastructure and alerts you when they fail. The difference is where the state lives. With a hosted service, the checks, the incident history and the alerting pipeline belong to the vendor, and you pay for them. With Upptime, all three belong to your GitHub account, and the README's claim is that this makes it free if you are already using GitHub. That trade cuts both ways. A hosted monitor keeps working when your other infrastructure does not, because it runs somewhere else. Upptime runs inside the same platform that hosts a large share of the services it watches, so a GitHub-wide incident is both an outage you cannot see and an outage that hides it. For a personal project or an internal status page, that is an acceptable trade. For a public status page with an SLA behind it, it is the reason to look elsewhere. ## Maintenance, licence and what the repository tells you The repository is not archived, but the last push was on 2020-10-13, and the most recent release is v2.0.0 from the same date. That is a long gap. The README still describes the project as actively used, and it is a template that people fork, so an unchanged upstream does not mean the pattern is dead. It does mean you should expect to maintain your fork yourself, and that any bug in the workflows is yours to fix. The licence is MIT. That permits commercial use, modification and redistribution, provided the copyright notice and permission notice are included. It does not give you any warranty, and it says nothing about the availability of GitHub Actions or Pages, which are governed by GitHub's own terms. The README does not address what happens to your history if you move the repository or change its visibility, so check that against your own requirements rather than assuming it is covered. ## Conclusion Adopt Upptime if your services are already on GitHub and you want checks, incident issues and a status page in one repository you control. Do not adopt it if you need checks faster than the five-minute schedule, monitoring that survives GitHub outages, or a vendor to call during an incident. Before committing, verify that Actions minutes and Pages are enabled for the account, and read the workflows in .github/ to see exactly what runs on each schedule. ## FAQ ### What is Upptime? Upptime is an open-source uptime monitor and status page powered entirely by GitHub Actions, Issues and Pages. Checks run on a schedule, results are committed to git, and downtime opens a GitHub issue. ### What is a good uptime for a monitored service? The README does not state a target uptime figure. The demo status table it shows reports 100.00% for the example sites, which is the value Upptime computes from the checks it has recorded, not a recommendation. ### Is uptime the same as an SLA? The README does not discuss SLAs. Upptime records whether an endpoint responded and how long it took, and that record is what appears on the status page; it does not define contractual commitments. ### What is the best tool for monitoring uptime? There is no single answer, and the README does not rank tools. Upptime is one option when you already use GitHub and want the checks, incident issues and status page in one repository you control. ## Sources - [Official documentation](https://upptime.js.org) - [Official README](https://github.com/upptime/upptime#readme) - [Project repository](https://github.com/upptime/upptime) - [Release notes](https://github.com/upptime/upptime/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/upptime-upptime