First monitor

Monitor types

Type	What it checks
HTTP / HTTPS	URL availability, status code, response body, keyword, SSL certificate
Ping (ICMP)	Host reachability via ICMP ping

This guide uses HTTP, the most common type. The steps for a ping monitor are nearly identical.

---

Create an HTTP monitor

1. In the sidebar, click Monitors.
2. Click + New Monitor and select HTTP / HTTPS.
3. Fill in the required fields:

Field	Value	Why
Name	Production API	Display label shown in the monitor list and in alerts.
URL	https://api.example.com/health	The endpoint the prober requests on every check.
Check interval	120s	How often the check runs. 120s is the Uptime Free minimum; paid Uptime plans allow down to 15s.
Expected status	2xx (default)	Any 2xx response counts as up — override it if your endpoint returns a different success code.

4. Click Save.

The first check runs within a few seconds. You should see the status indicator turn green if the endpoint responds with a 2xx status.

---

Optional: keyword check

If your endpoint can return HTTP 200 with an error body (common with some frameworks), add a keyword check:

1. In the Advanced section, find Keyword check.
2. Enter a string that must appear in the response body, for example, "status":"ok".
3. If the keyword is absent, the check fails even if the HTTP status is 2xx.

---

Optional: SSL monitoring

For HTTPS monitors, enable SSL certificate monitoring to receive alerts before your certificate expires:

1. Enable SSL monitoring in the Advanced section.
2. Set warning thresholds (default: warn at 30 days, critical at 7 days).

---

Alert threshold

The alert threshold controls how many consecutive failures must occur before an alert is opened:

• 2 (default): wait for 2 consecutive failures. Reduces alert fatigue from transient network blips.
• Retry on fail: the prober re-checks itself, so 1 confirmed failure is enough. Best for critical production endpoints.
• 3 or more: wait for N consecutive failures for noisier services.

---

Prober regions

Checks run from our global prober regions: Nuremberg (EU), Helsinki (EU), N. California (US), and Singapore (Asia). When a monitor is checked from more than one region, results are combined:

• All regions fail → monitor status: Down
• Some regions fail → monitor status: Degraded

See Concepts: Monitors for a full explanation of regions and degraded state.

---

Verify the monitor is working

After saving, the monitor list shows:

• Status: Up / Down / Degraded
• Last check: timestamp of the most recent check
• Response time: latest measured latency
• Uptime %: rolling 24-hour figure

Click the monitor name to open the detail page, which includes a 90-day uptime bar (illustrative sample below) and incident history:

---

What's next

• First heartbeat: monitor cron jobs and background workers
• First status page: publish uptime data publicly
• Concepts: Monitors: deep dive into all monitor options