Upptime: A Git-Native Uptime Monitor That Runs Entirely on GitHub Actions

The Problem: Expensive and Closed Uptime Services

Upptime addresses a common pain: uptime monitoring and status pages are often paid, rigid, or closed-source. The author built it for his startup because existing services felt expensive and inflexible. The solution is to use GitHub's own infrastructure as the monitoring engine. This makes it free if you already use GitHub, since there is no external server or subscription. The target user is a developer or small team who wants a configurable monitor with a public status page, without leaving the GitHub ecosystem. It is not aimed at enterprises needing distributed probes or advanced alerting.

Architecture: Actions for Checks, Issues for Incidents, Pages for the Site

Upptime's mechanism is straightforward but clever. Scheduled GitHub Actions workflows run checks as often as every 5 minutes. Each check pings an endpoint and verifies it is online. Response time data is recorded and committed to git, which creates a long-term trend history. When downtime is detected, GitHub Issues are automatically opened, and when the endpoint recovers, the same issue is closed. A status page built with Svelte is hosted on GitHub Pages, displaying uptime percentages, response times, and incident history. The data flow is: Actions perform checks, write results to the repository, and the static site reads those commits. This design means every change is tracked in git, providing an audit trail of all monitoring events.

Setup: A Single Config File and a Template Repository

Getting started is designed to be low-friction. The README states that all configuration lives in a single file. The typical path is to use the Upptime template repository to create a new repo, then edit a configuration file (likely .upptimerc.yml or similar, though the README excerpt does not name the exact file). The repository includes multiple workflow files: uptime.yml, response-time.yml, graphs.yml, site.yml, and summary.yml. These workflows handle the periodic checks, response time recording, graph generation, and static site deployment. The documentation mentions that the status page is generated by Upptime and tells users not to edit the generated summary manually, as changes will be overwritten. This suggests that the setup is mostly declarative: you configure endpoints and let the workflows do the rest.

What You Get: Status Page, History, and Incident Tracking

The live status page example shows a table with URL, status, history link, response time, and uptime percentage. Each endpoint has a history file (e.g., google.yml) committed to the repo, which can be viewed on GitHub. The status page is not just a simple green/red indicator; it includes response time summaries and uptime percentages. The README mentions 'long-term trend charts and historical insights,' which implies the graphs workflow generates visualizations from the recorded data. The use of GitHub Issues for incidents means that each downtime event is tracked as an issue with its own timeline, which can be referenced and discussed. This is a unique feature: incident management is integrated into the same platform that hosts the code.

Limitations: Frequency, Geography, and GitHub Dependency

The most obvious limitation is the 5-minute minimum check interval. If you need sub-minute monitoring, Upptime is not the right tool. Also, all checks originate from GitHub Actions runners, which are in a limited set of regions. This means you get no geographic diversity, and you cannot simulate user traffic from different parts of the world. Another significant limitation is that the entire system depends on GitHub. If GitHub is down, so is your monitoring, and your status page will not be reachable. The README itself notes that 'your data is gone if you delete the repo,' which is a stark reminder that the repository is the single source of truth. There is no external backup. Finally, GitHub Actions has usage limits, and running checks every 5 minutes for many endpoints could consume your monthly minutes allowance.

Alternatives: Traditional Monitors and Self-Hosted Tools

A common alternative is a dedicated uptime monitoring service like UptimeRobot or Pingdom. These offer checks from multiple global locations, more frequent intervals (often every 1 minute), and phone/email alerts. The key difference is that these are hosted services with a subscription cost, whereas Upptime is free and self-contained within GitHub. Another alternative is to run your own monitoring stack, such as Prometheus with Blackbox Exporter, which gives you complete control over probes and alerting but requires you to maintain a server. Upptime sits in between: it is more flexible than a closed SaaS but less powerful than a dedicated self-hosted solution. The trade-off is zero infrastructure cost versus limited probe locations and check frequency.

Maintenance and License: MIT and a Stalled Project

Upptime is released under the MIT license, which means you can use, modify, and distribute it freely, even commercially. The project's last push was on October 13, 2020, with v2.0.0 released on the same day. The repository is not archived, but the lack of recent activity is a concern. This means that if you adopt Upptime, you may need to fork it and maintain your own patches if you encounter issues. The documentation and workflows are tied to the state of GitHub Actions as of 2020, and there is a risk that future changes to GitHub Actions could break the workflows. You should check the repository's issues and pull requests to see if there is active community support or if it is effectively dormant. The MIT license gives you the freedom to maintain it yourself, but that is a cost to factor in.

Editorial conclusion

Adopt Upptime if you are already on GitHub, want a zero-cost monitor for a handful of endpoints, and value a git-backed audit trail and a static status page. Avoid it if you need checks more frequently than every 5 minutes, require monitoring from multiple geographic regions, or want a status page that does not depend on GitHub's availability. Before adopting, verify that your endpoints are reachable from the GitHub Actions runner's IP range, and confirm that your repository's Actions minute quota covers the scheduled workflows. Also check the project's maintenance status: the last push was in October 2020, so review open issues and pull requests to see if the project is still actively maintained for your use case.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes