A Simple Way to Track Website Uptime Without Paying

There’s a familiar moment many developers have faced. You find out your website or app was down not from your system, but from a user. It’s uncomfortable, and honestly, avoidable.

Uptime monitoring might sound like something only large companies worry about, but even small projects benefit from it. Whether it’s a personal portfolio, an API, or a side project, knowing when things break matters. The issue is that many monitoring tools either cost money, require extra infrastructure, or feel overly complicated.

There is a simpler alternative.

What uptime monitoring actually is

In simple terms, uptime monitoring is a repetitive check.

A system periodically sends requests to your website or service and records the outcome. If everything responds as expected, it logs success. If something fails, it raises an alert.

This helps you:

• Detect issues early
• Measure how stable your system is
• Maintain user trust

Even short downtime can affect how people perceive your work. For products, it can mean lost users. For personal projects, it can signal neglect.

Using GitHub as your monitoring system

Most monitoring tools rely on their own servers, which is where costs and complexity come in.

Upptime offers a different idea.

Instead of building a separate backend, it uses tools you already know:

• GitHub Actions to run scheduled checks
• GitHub Issues to log incidents
• GitHub Pages to host a status page

Everything runs inside GitHub, so you don’t need to manage any servers.

What happens behind the scenes

Once configured, everything runs automatically.

• Every five minutes, your endpoints are checked
• If something fails, an issue is created
• When it recovers, the issue is closed
• Response times are recorded over time
• A status page is generated and updated

Your repository becomes a full record of uptime and incidents.

There’s no external dashboard or hidden storage. Everything is visible and version-controlled.

How to set it up

Getting started doesn’t take long, even if you’re not deeply into DevOps.

1. Create a repository

Use the Upptime template to generate your own repository.

2. Enable workflows

Go to the Actions tab and allow workflows to run.

3. Turn on GitHub Pages

In settings, select the gh-pages branch as the source.

4. Add a personal access token

Create a token with permissions for Actions, Contents, Issues, and Workflows. Then save it as:

GH_PAT

5. Configure your services

Edit:

.upptimerc.yml

Example:

owner: your-github-username
repo: your-repo-name

sites:
  - name: Website
    url: https://yourwebsite.com
  - name: API
    url: https://api.yourwebsite.com

assignees:
  - your-github-username

status-website:
  name: My Status Page

Commit and push your changes.

6. Check if it works

After a few minutes:

• Workflows will run
• Your README will show status badges
• Your status page will be live

If everything shows green, your monitoring is active.

Setting up alerts

Monitoring is only useful if you’re notified when something goes wrong.

You can connect it to:

• Slack
• Discord
• Telegram
• Email
• SMS

Example:

notifications:
  - type: slack
    webhook: $SLACK_WEBHOOK_URL

Alerts typically include the service name, URL, response code, and a link to the issue.

Some helpful features

Monitor non-HTTP services

You can track services like databases:

- name: Database
  url: tcp:your-server.com:5432

Check response content

You can validate if the correct content is returned:

- name: Homepage
  url: https://yourwebsite.com
  body: "Welcome"

Add badges to your README

You can display uptime metrics directly in your repository using badge URLs.

These updates are automatically as new data is recorded.

Cost and limitations

For public repositories, this setup is completely free.

There are no subscriptions or usage-based pricing.

However, a few limitations exist:

• Checks run every five minutes, not instantly
• Workflow execution may occasionally be delayed
• The status page is not truly real-time

For most use cases, these trade-offs are reasonable.

Why this approach stands out

What makes this setup interesting is how it uses tools you already rely on.

Instead of adding another service to your stack, it integrates monitoring into your existing workflow. Your uptime data becomes part of your repository, just like your code.

You are not just monitoring your system. You are keeping a transparent and versioned record of its performance.

Conclusion

If you’ve been postponing uptime monitoring because it seemed costly or complicated, this approach removes both concerns.

With minimal setup, you get:

• Automated checks
• Incident tracking
• A public status page
• Historical performance insights

And it all runs quietly in the background.

Sometimes the simplest solutions come from rethinking how we use the tools we already have.

Reference:

How to Monitor Uptime Status of Your Website or App for Free