Schedule the DeskUptime GitHub Action and get uptime, SSL-expiry and content-change checks every 30 minutes. The workflow fails when your site goes down, so GitHub alerts you. Works with any website, any stack.
You already pay for CI minutes. A scheduled workflow is a free uptime monitor for anything with a URL.
No SaaS subscription, no seat limits, no per-check pricing. Public repos are unlimited; private repos fit comfortably in the free minutes tier.
A failed run triggers GitHub's built-in notifications — email, Slack, mobile push. Nothing extra to configure.
Websites, APIs, health endpoints, status JSON. Plain HTTP checks mean no agent installs and no platform lock-in.
Fail the job when a certificate expires within N days — catch the classic expired-cert outage before your users do.
Every run writes a Markdown table of results: status codes, response times, SSL days remaining, content hash.
Powered by the open-source DeskUptime engine — the same checks as the desktop app, running headless.
Add this workflow file to any repository. That's the whole installation.
.github/workflows/monitor.yml
name: Monitor
on:
schedule:
- cron: '*/30 * * * *' # every 30 minutes
workflow_dispatch:
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: mahope/deskuptime@v0
with:
urls: |
https://yoursite.com
https://api.yoursite.com/health
fail-on-ssl-expiry-days: '14'
- name: Alert on failure
if: failure()
run: echo "A monitored site is down!" # wire to Slack/email/webhook here
That's it. Commit the file and enable scheduled workflows. The first run appears in the repository's Actions tab.
| Input | Default | Description |
|---|---|---|
urls | (required) | Space- or newline-separated URLs to check |
fail-on-down | true | Fail the step (exit 2) if any URL is unreachable or returns 5xx |
fail-on-ssl-expiry-days | 0 | Also fail if an HTTPS URL's certificate expires within N days (0 = off) |
summary | true | Write a Markdown results table to $GITHUB_STEP_SUMMARY |
Outputs: json (full results array) and down-count — usable by later steps for custom alerting.
Where a CI-based monitor fits — and where it doesn't.
| GitHub Action (free) | Dedicated SaaS ($7–15/mo) | DeskUptime desktop ($19 once) | |
|---|---|---|---|
| Check interval | ~5 min granularity (cron minimum) | 10–60 seconds | Continuous (while machine runs) |
| Multi-region probes | — (single region) | — (your location) | |
| Cost | $0 | $84–180/year | $19 one-time |
| Setup | One YAML file | Account + dashboard | Install + license key |
| Best for | Personal projects, APIs, repos | Teams with SLAs | Freelancers watching client sites |
Scheduled workflows can be delayed or skipped during peak GitHub load, and cron schedules pause after 60 days of repository inactivity. For business-critical SLAs, use a purpose-built service.
For personal sites, side projects and internal tools, yes. Scheduled workflows usually run within a few minutes of their schedule, but GitHub doesn't guarantee exact timing under load. Teams with strict SLAs should use a dedicated monitor.
Nothing for public repositories. Private repositories include 2,000 free minutes per month; a check takes about one minute per run, so checking every 30 minutes uses roughly 1,500 minutes a month.
Yes. The action fetches any public URL over plain HTTP(S) — WordPress, Shopify, Webflow, static sites, API health endpoints. No agent, no plugin, no platform lock-in.
The step exits with code 2 and the workflow run is marked failed. GitHub notifies you through its standard channels, and you can wire any custom alerting step on failure.