Uptime Monitors

Monitor your websites, APIs, and services with HTTP checks and get instant alerts when they go down.

Uptime monitors continuously check the health of your web services by sending HTTP requests at regular intervals. When a monitor detects that your service is down or responding with unexpected status codes, it automatically creates an incident and sends you alerts.

Each monitor has a protocol. HTTP, DNS, TCP, gRPC, and UDP can be created. TCP and TCP/TLS are the same protocol, tcp. TLS is a boolean on that monitor, not a separate protocol. Omitting the protocol creates an HTTP monitor, and the protocol cannot be changed later. The canonical target for an HTTP monitor is its URL. A DNS monitor queries a public DNS name for an A, AAAA, or CNAME record using each zone's resolver. Optional expected values must all be present: order and duplicates are ignored, hostnames are case-insensitive and ignore a trailing dot, and IP addresses are exact. NXDOMAIN, SERVFAIL, timeout, and an empty record set fail the target. The canonical target is the DNS name plus the record type. For TCP it is host:port, with TLS when the handshake is required. For gRPC it is host:port, plus the service name when one is set. For UDP it is host:port. Targets must be public addresses: private, loopback, link-local, and reserved networks are rejected when you save the monitor and again before each check. A private address in a DNS answer is a result, not a connection. The default timeout is 10 seconds (1–30). One attempt is made per zone. A check that gets no target result from any zone is saved as inconclusive: it stays visible, and it does not change status, uptime, or incidents.

TCP and TCP/TLS

A TCP monitor opens one connection to a public host and port. It is up when that connection is established within the timeout. Turn on TLS when the service must also complete a handshake with a valid trust chain and a hostname check against the system trust store. The server name (SNI) defaults to the target hostname and is required when the target is an IP address and TLS is on. All ports to public destinations are allowed.

There is no payload, banner match, or retry, and no separate SSL incident. Connection refused, timeout, DNS errors, and invalid TLS are target failures. A worker fault stays inconclusive, so it does not mark the target down. Alerts, incidents, the status page, the badge, and the event stream report the cause and the failed zones. They do not include a payload or secrets. Useful certificate details (issuer, subject, and not-after) are stored on the check.

gRPC Health

A gRPC monitor calls grpc.health.v1.Health/Check once per zone. It is up only when the status is SERVING. Any other health status, a timeout, a transport error, or invalid TLS is a target failure. TLS is a boolean on the same grpc protocol, not a separate protocol. It checks the trust chain and hostname with the system trust store. The authority (SNI) is optional. When it is empty, SNI defaults to the hostname. The service name is optional: an empty name checks the server, and a name checks that service.

There is no metadata, authentication, arbitrary RPC, or separate SSL incident. A worker fault stays inconclusive and does not mark the target down. Alerts, incidents, the status page, the badge, and the event stream report the health status, the cause, and the failed zones. They do not include metadata or secrets. The check stores the health status, latency, error, and outcome.

UDP

A UDP monitor sends one datagram to a public host and port and waits for one reply. The payload is either text (UTF-8 bytes) or hex (decoded bytes), at most 256 bytes after decoding. The expected response is a pattern of 1–256 bytes, compared exactly or as a substring. The check is up only when a reply arrives within the timeout and matches. No reply is a target failure. A reply larger than 1024 bytes is a target failure and is not stored. There is no second datagram, retry, or session.

Mismatch, timeout, and an oversized reply are distinct target failures. A worker fault stays inconclusive and does not mark the target down. Private, loopback, link-local, and reserved addresses are rejected when you save the monitor and again after DNS resolution. Alerts, incidents, the status page, the badge, and the event stream report the cause and the failed zones. They do not include the payload or the reply. The check stores the comparison mode, payload length, latency, error, and outcome.

Creating Your First Monitor

Monitor Configuration

HTTP Methods

Choose the appropriate HTTP method for your endpoint:

• GET — Most common method for health checks and status endpoints
• POST — Useful for APIs that require data submission to check health
• HEAD — Lightweight option that only checks headers without downloading the full response

Valid HTTP Status Codes

Configure which HTTP status codes should be considered successful responses. The check compares the final response status against this list:

// Standard Web Service
[200]

// API with Multiple Success Codes
[200, 201, 202]

// Redirecting Service
[200, 301, 302]

Basic Authentication

For endpoints that require basic HTTP authentication, enable the option in your monitor configuration, enter your credentials (encrypted and stored securely), then save and verify.

Check mode

Each monitor has a check mode: round robin (the default) or parallel.

• Round robin — every check runs from exactly one selected zone, rotating in a fixed order. You may select any number of available zones. Consensus threshold and partial down do not apply. If a zone fails the target, Upcron immediately confirms from the next zone in the same check before marking the monitor down.
• Parallel — every check runs from all selected zones at once (at most four). Health uses the consensus threshold and may be partial down. How many parallel monitors you can have depends on your subscription plan; the parallel quota is a subset of your total monitor limit.

Multi-Zone Monitoring

Each monitor runs its checks from one or more geographic zones. Choose zones representative of your users so an outage that only affects one region does not silently stay undetected, or ignore local network issues that affect a single zone.

Available zones

Selected zones

For parallel monitors, select between 1 and 4 zones. For round robin monitors, you may select any available zones. The default selection is eu-fra1. Only the selected zones run the checks and participate in the result; zones without an available worker endpoint are hidden from the selector so they cannot cause false failures.

Consensus threshold

On parallel monitors, a check is evaluated against the consensus threshold: the percentage of selected zones that must fail for the monitor to be considered down. Below that percentage the monitor is marked partially down (degraded) rather than fully down.

For example, with four zones and a threshold of 50%, two or more failed zones mark the monitor down, while a single failed zone keeps it partially down. Round robin monitors ignore this setting.

SSL monitoring

For HTTPS monitors, Upcron also checks the TLS certificate during the check and records its state on the monitor: certificate status (valid, expiring or expired) and expiration date.

• The SSL exp. column on the monitors list shows the certificate expiration for each monitor
• When a certificate is expiring or expired, an SSL incident is opened (typed separately from uptime incidents, also visible with the other incident types)
• SSL checks are skipped while the monitor is in a maintenance window

Monitor Status

Best Practices

Choose the Right Endpoints

Monitor endpoints that are critical to your service functionality:

# Good endpoints to monitor
https://api.example.com/health
https://example.com
https://api.example.com/status

# Avoid monitoring
# Internal admin pages
# Endpoints with side effects
# Pages that require user interaction

Organize with Projects

• Production — Critical production services
• Staging — Development and testing environments
• Third-party — External services you depend on
• Infrastructure — Database, cache, and infrastructure endpoints

Use Descriptive Names

Choose clear, descriptive names: "Production API Health Check", "Website Homepage", "Payment Gateway Status" — not "Monitor 1" or "Test".

Dashboard Overview

Your monitor dashboard shows:

• Current Status — Up/Down status for each monitor
• Uptime Percentage — Calculated uptime over time
• Last Checked — When the monitor was last verified
• Incident Count — Number of incidents in the last 30 days
• Response Time — Average response times

Uptime is calculated as: (Successful checks / Total checks) × 100

App screens reference

Monitors list

The Monitors page lists the monitors of the current project with a filter tab, search and per-page pagination:

Create / edit monitor form

Fields available when creating or editing a monitor:

Monitor detail

The detail page shows the current state, key numbers and the last check breakdown:

• KPIs — State, Uptime (30d), Average latency (24h), Incidents (90d)
• Actions — Pause/Resume, Edit, Run check (manual check with result flash)
• Timeline — response time series of recent checks
• Per-zone results — one row per zone with HTTP, DNS, TTFB, connection, total time, duration, start time and message
• Export — CSV export of check data; Created at shown in the header

Firewall & bot protection (Cloudflare)

Checks run from geographic zone workers and identify themselves with the User-Agent Upcron/1.0 (https://upcron.io). If your site is protected by Cloudflare, Bot Fight Mode or Super Bot Fight Mode can block our worker until it is approved from your dashboard.

1. Allow the User-Agent — in Cloudflare, open Security → Bots → Super Bot Fight Mode and allow the value Upcron/1.0 (https://upcron.io).
2. Or use a WAF custom rule — create a rule that bypasses bot management when the User-Agent equals Upcron/1.0 (https://upcron.io).
3. Re-check the monitor — pause and resume the monitor, or wait for the next scheduled check, to confirm the block is gone.

Troubleshooting