Quickstart

Go from empty account to your first real-time alert in under three minutes. We'll set up one HTTPS monitor, connect email notifications, and trigger a test alert.

Step 1 — Create your account

Head to uptimebeacon.org/register and sign up with Google or email. No credit card needed for the Hobby plan.

Step 2 — Add your first monitor

From the dashboard, click Add monitor. Choose HTTP / Website, paste your URL, and hit save. We'll start checking it within 60 seconds.

Step 3 — Configure alerts

Navigate to Alerts and confirm your email address. You'll get a notification the moment your site goes down and another when it recovers.

Step 4 — Watch the dashboard

The Overview shows live uptime status, response times, and recent incidents for all your monitors. You're done.

Core concepts

A quick tour of the building blocks — monitors, incidents, alerts, and status pages — before you dive deeper.

Monitors

A monitor is a single endpoint we watch on a schedule. It can be an HTTP URL, a hostname to ping, a TCP port, or an SSL certificate. Each monitor tracks status (up, down, paused) and a rolling uptime percentage.

Incidents

An incident opens automatically the first time a monitor fails and closes when it recovers. Incidents are the source of truth for alert deduplication — we notify you once when the incident opens, and once when it closes. No spam.

Alerts

Alerts are the notifications sent when incidents open or close. You can route them to email, Slack, Discord, or any webhook. Configure them per-monitor or globally under Alerts.

Status pages

Every account gets a public-facing status page that shows the real-time and historical status of your chosen monitors. Share it with customers so they always know what's going on — before they ask.

Monitor types

UptimeBeacon supports six monitor types. Each is tuned for a specific failure mode — pick the narrowest one that covers your case.

How to choose

Use HTTP for any public URL. Prefer API when you care about the request body or a non-200 response code. Use Keyword when a 200 OK isn't enough — e.g., you want to confirm \"status\":\"healthy\" is actually in the response body. Use Ping for servers that don't expose HTTP. Use Port for databases, mail servers, and anything TCP.

Check regions

Checks currently run from a single distributed worker. Multi-region checking — where each monitor is verified from several locations simultaneously — is on our roadmap.

Current setup

All monitors are checked from a central worker node. The worker polls your endpoint on the configured interval and records the result. If the check fails, a confirmation check runs immediately before creating an incident — this eliminates most transient false positives.

Confirmation logic

When a check fails, the worker immediately retries once before opening an incident. This prevents transient network errors from triggering unnecessary alerts.

SSL monitoring

UptimeBeacon tracks TLS certificate expiry and alerts you with enough lead time to renew without scrambling.

How it works

Create an SSL certificate monitor pointing to any HTTPS hostname. We check the cert chain once per hour and flag the monitor as warn when fewer than 14 days remain, and down at 3 days or on any handshake error.

What triggers an alert

• Certificate expires in < 14 days
• Certificate already expired
• Hostname mismatch
• Self-signed or untrusted chain
• TLS handshake fails entirely

Alert channels

Configure where UptimeBeacon sends notifications when incidents open and close. Each channel can be set globally or overridden per monitor.

Supported channels

• Email — Available on all plans. Sent to your account email address.
• Slack — Starter and above. Paste any incoming webhook URL to get started.
• Discord — Starter and above. Uses Discord's webhook format natively.
• Webhooks — Starter and above. POST JSON to any URL on down and recovery.

Alert deduplication

We send one alert when an incident opens and one when it resolves — never more. If your site bounces between up and down within the same incident window, you will not receive a flood of notifications.

Incidents

An incident is the authoritative record of an outage. It opens on the first failed check and closes automatically when the monitor recovers.

Incident lifecycle

1. Monitor check fails → incident created → down alert sent.
2. Subsequent failures → incident stays open → no further alerts.
3. Monitor check passes → incident closed → recovered alert sent.

Severity levels

• Critical — Complete failure, check returns no response.
• Warning — Degraded response times or unexpected status codes.
• Info — SSL expiry warnings and non-HTTP check results.

Slack

Get down and recovery notifications posted directly to a Slack channel. Takes about 90 seconds to set up.

Setup

1. In Slack, go to Apps → Incoming Webhooks and create a new webhook for the channel you want alerts in.
2. Copy the webhook URL (starts with https://hooks.slack.com/services/…).
3. Go to Integrations in your UptimeBeacon dashboard, click Add webhook, choose type Slack, and paste the URL.
4. Save. The next incident will post a formatted message with the monitor name, status, cause, and timestamp.

Webhooks

POST a JSON payload to any URL when an incident opens or closes. Use it to build custom workflows, fan out to multiple systems, or pipe data into your own backend.

Payload format

{
  "event":      "incident.opened",
  "monitor_id": 42,
  "monitor_name": "API Gateway",
  "monitor_url":  "https://api.example.com/health",
  "status":     "down",
  "cause":      "Connection timed out",
  "started_at": "2026-05-19T14:30:00Z",
  "region":     "eu-west"
}

For incident.resolved events, a resolved_at field and duration_seconds are also included.

Securing your endpoint

Each webhook delivery includes an X-UptimeBeacon-Signature header containing an HMAC-SHA256 of the raw body signed with your webhook secret. Verify this signature before processing the payload.

PagerDuty

Native PagerDuty integration is not yet available. This page describes the planned behaviour when it ships.

Workaround via webhooks

You can already connect UptimeBeacon to PagerDuty using the generic webhook integration. Configure an outgoing webhook and point it at PagerDuty's Events API v2 endpoint (https://events.pagerduty.com/v2/enqueue). The JSON payload will need to be adapted by a small proxy or serverless function.

Public status pages

A public status page lets your customers see the real-time health of your services — before they file a support ticket.

Creating a status page

Go to Status Pages in your dashboard and click New page. Give it a name, pick which monitors to show, and you're live.

Customising

• Logo & colours — Upload your logo and set a primary colour on Starter+.
• Custom domain — Point a CNAME at status.uptimebeacon.org and enter your domain in settings (Starter+).
• Incident messages — Post public updates on ongoing incidents directly from the Incidents tab.

Authentication

The UptimeBeacon REST API is currently in early access. Endpoints are available but full authentication and user-scoped responses are still being rolled out.

Base URL

https://uptimebeacon.org/api/

Available endpoints

Currently open endpoints: GET /api/health, GET /api/monitors, POST /api/monitors. Full CRUD and user-scoped access coming soon.

Monitors API

Create, read, update, and delete monitors programmatically. All endpoints return JSON.

List monitors

Returns an array of all monitors belonging to the authenticated user.

Get a monitor

Create a monitor

{
  "name": "Production API",
  "url":  "https://api.example.com/health",
  "type": "api",
  "http_method": "GET",
  "expected_status": 200
}

Delete a monitor