Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

5 Commits
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

CCLabs Uptime Monitor

Uptime monitor for all CCLabs projects, powered by Upptime. Checks every 5 minutes and sends WhatsApp alerts via CallMeBot when a site goes down or recovers.

Status page: https://cclabsnz.github.io/uptime/

Monitored Sites

Site URL
Blastwave https://blastwave.vercel.app
AI Mortgage Platform https://ai-mortgage-platform.vercel.app
Mehfil https://mehfil.vercel.app
Software Insights Blog https://software-insights-blog.vercel.app
ClearBill (Paywren) https://paywren.vercel.app
CloudCounsel Website https://cloudcounsel-website.vercel.app
VCards https://vcards.vercel.app
SF Audit https://sf-audit.vercel.app
InstantCards https://instantcards.co.nz

Setup (one-time)

1. GitHub Personal Access Token

Go to https://github.com/settings/tokens β†’ Generate new token (classic)

  • Note: upptime
  • Scopes: repo (full control)

Add it as a secret named GH_PAT at: https://github.com/cclabsnz/uptime/settings/secrets/actions

2. CallMeBot WhatsApp Alerts

  1. Save +34 644 59 21 48 as a WhatsApp contact (name it "CallMeBot")
  2. Send this exact message to that contact:
    I allow callmebot to send me messages
    
  3. CallMeBot will reply with your API key

Add two secrets at https://github.com/cclabsnz/uptime/settings/secrets/actions:

Secret Value
CALLMEBOT_PHONE Your WhatsApp number in international format, e.g. +6421xxxxxxx
CALLMEBOT_APIKEY The API key from CallMeBot's reply

3. Enable GitHub Pages

Go to https://github.com/cclabsnz/uptime/settings/pages

  • Source: Deploy from a branch
  • Branch: gh-pages / / (root)
  • Click Save

The gh-pages branch is created automatically on the first workflow run. Trigger it manually first if it doesn't appear: Actions β†’ Uptime CI β†’ Run workflow.

4. First run & test

Trigger the first run: Actions β†’ Uptime CI β†’ Run workflow

To test WhatsApp alerts, add a fake site to .upptimerc.yml, push, trigger the workflow, then remove it:

- name: Test Down Site
  url: https://this-url-does-not-exist-cclabsnz.vercel.app

Adding more sites

Edit .upptimerc.yml and add entries under sites::

- name: My New App
  url: https://my-new-app.vercel.app

Uptime CI Response Time CI Static Site CI

Upptime (https://upptime.js.org) is the open-source uptime monitor and status page, powered entirely by GitHub Actions, Issues, and Pages. It's made with πŸ’š by Anand Chowdhary, supported by Pabio.

I find Upptime an incredible clever usage of [GitHub Actions]. You essentially get a free configurable uptime monitor for whatever you want. – CSS Tricks

Upptime is used by 3,000+ people and teams to ensure they know when their endpoints go down.

I built Upptime because, like many developers, I needed an uptime monitor and status page for my startup Pabio that was affordable, flexible, and completely under my control. At the time, existing services felt expensive, rigid, or closed-source. GitHub Actions had just launched, and I thought: hmm... what if I turned Actions into a self-hosted uptime monitor?

Upptime runs scheduled checks using GitHub Actions (as often as every 5 minutes) to ping your endpoints and verify they're online. Response time data is recorded and committed to git, enabling long-term trend charts and historical insights. When downtime is detected, GitHub Issues are automatically opened and closed. A status page built with Svelte is hosted via GitHub Pages and shows uptime, response times, and incident history - so you get the full-stack uptime monitor and status page.

I built it to be completely free if you're already using GitHub since there's no external server or subscription needed. All configuration lives in a single file, and your data is gone if you delete the repo. Plus, you get a git-native audit trail for all changes and events.

Since launching, Upptime has grown to over 16,000 stars and is actively used by developers and teams to monitor their services. In fact, Upptime is used by over 3,000+ people and teams, including Ubuntu-maker Canonical and my preferred developer time tracker Wakatime.

Uptime CI Response Time CI Graphs CI Static Site CI Summary CI

πŸ“ˆ Live Status: 🟧 Partial outage

URL Status History Response Time Uptime
Google 🟩 Up google.yml
Response time graph 95ms
Response time 131
24-hour response time 57
7-day response time 95
30-day response time 139
1-year response time 134
100.00%All-time uptime 99.99%
24-hour uptime 100.00%
7-day uptime 100.00%
30-day uptime 99.70%
1-year uptime 99.95%
Wikipedia 🟩 Up wikipedia.yml
Response time graph 148ms
Response time 197
24-hour response time 81
7-day response time 148
30-day response time 168
1-year response time 207
100.00%All-time uptime 100.00%
24-hour uptime 100.00%
7-day uptime 100.00%
30-day uptime 100.00%
1-year uptime 100.00%
Hacker News 🟩 Up hacker-news.yml
Response time graph 287ms
Response time 311
24-hour response time 359
7-day response time 287
30-day response time 285
1-year response time 308
100.00%All-time uptime 99.07%
24-hour uptime 100.00%
7-day uptime 100.00%
30-day uptime 100.00%
1-year uptime 99.98%
Test Broken Site πŸŸ₯ Down test-broken-site.yml
Response time graph 0ms
Response time 0
24-hour response time 0
7-day response time 0
30-day response time 0
1-year response time 0
0.00%All-time uptime 0.00%
24-hour uptime 0.00%
7-day uptime 0.00%
30-day uptime 1.38%
1-year uptime 0.00%

⭐ How it works

  • GitHub Actions is used as an uptime monitor
    • Every 5 minutes, a workflow visits your website to make sure it's up
    • Response time is recorded every 6 hours and committed to git
    • Graphs of response time are generated every day
  • GitHub Issues is used for incident reports
    • An issue is opened if an endpoint is down
    • People from your team are assigned to the issue
    • Incidents reports are posted as issue comments
    • Issues are locked so non-members cannot comment on them
    • Issues are closed automatically when your site comes back up
    • Slack notifications are sent on updates
  • GitHub Pages is used for the status website
    • A simple, beautiful, and accessible PWA is generated
    • Built with Svelte and Sapper
    • Fetches data from this repository using the GitHub API

Upptime is not affiliated to or endorsed by GitHub.

Screenshot of status website

πŸ‘©β€πŸ’» Documentation

  1. How it works
  2. Getting started
  3. Configuration
  4. Triggers
  5. Notifications
  6. Badges
  7. Packages
  8. Contributing
  9. Frequently Asked Questions

Concepts

Issues as incidents

When the GitHub Actions workflow detects that one of your URLs is down, it automatically opens a GitHub issue (example issue #67). You can add incident reports to this issue by adding comments. When your site comes back up, the issue will be closed automatically as well.

Screenshot of GitHub issue Screenshot of incident page

Commits for response time

Four times per day, another workflow runs and records the response time of your websites. This data is committed to GitHub, so it's available in the commit history of each file (example commit history). Then, the GitHub API is used to graph the response time history of each endpoint and to track when a site went down.

Screenshot of GitHub commits Screenshot of live status

πŸ“„ License

About

Uptime monitor for all cclabsnz projects

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages

Generated from upptime/upptime