Regional observations. Clear incidents. Controlled spending.

Create a monitor

Choose HTTP/HTTPS, an optional keyword expectation, a TCP port, or ICMP ping. Select one to three compatible locations, a check interval of at least five minutes on Free or one minute on a paid plan, and a timeout of 1–10 seconds. Set confirmation thresholds of 1–5 consecutive rounds. Monitor creation and settings require a personal owner or team owner/admin.

HTTP checks use GET, validate TLS, and do not follow redirects. The expected status range is configurable; keyword checks inspect at most 64 KiB and report unknown if the body cannot safely be inspected. TCP checks only connect; ping sends one bounded echo request from ping-capable hosts. This release does not support custom authentication headers, browser scripts, private network targets, SSL-expiry alerts or SMS. Email is available only when a verified sender is enabled and your account has a verified linked address.

Only monitor systems you own or are authorized to test. Use a public health endpoint without secrets in its URL. Private, loopback, link-local, metadata and other reserved addresses are blocked, including mixed DNS answers. The service pins validated DNS answers for each connection.

Understand the results

Each scheduled round creates one check per selected location. A strict majority determines the round result: two agreeing observations out of three, both out of two, or the single observation for a one-location monitor. A confirmed incident needs the configured number of consecutive failed rounds; recovery similarly needs consecutive successful rounds.

Expired leases, offline probes, local capacity limits and blocked targets are unknown, not customer outages. Unknown rounds reset confirmation streaks but do not resolve an existing incident. Stale observations also display unknown. A paused monitor has no new work; already leased checks may finish.

Observed availability is successful rounds divided by successful plus failed rounds. Unknowns, paused periods and time with no samples are not counted as uptime or downtime. The dashboard shows unknown counts separately. This is sampled availability, not a contractual SLA calculation.

Monthly plans and retention

Free includes 10 monitors, five-minute checks, one region and seven days of raw history. Starter is 9 USDC per calendar month for 25 monitors; Team is 29 USDC for 100. Both paid plans include one-minute checks, up to three regions per monitor and 30-day raw history. All plans include API access, webhooks, Slack, Discord, basic public status pages and 90-day summaries. There are no per-check overages or extra Uptime seat charges.

Choose a linked infrastructure billing identity, reserve the required regions and explicitly accept the price before purchasing. Paid activation deducts one calendar month immediately. Automatic renewal is opt-in. Duplicate request retries never purchase another month. Paid plan changes take effect at the next anniversary without proration; turning off renewal preserves your paid-through period. Paused monitors still use allowance, and pausing monitors does not cancel the workspace plan.

Insufficient credit, revoked funding authority or unavailable capacity stops renewal. Topping up does not back-bill missed months; reactivate explicitly. Existing legacy usage monitors retain their separately accepted per-check rate and lifetime cap until replaced or archived.

Raw results are automatically pruned after the accepted 7–30 day retention period. Daily summaries, resolved incidents and terminal alert records are retained for 90 days. Open incidents, monitor totals, credit ledger entries and request identities remain for reconciliation. Archiving removes public access and new work but is not immediate deletion of financial records.

Alerts and signed webhooks

Supply an HTTPS receiver to receive confirmed incident and recovery events. The URL is encrypted at rest and never sent to probe nodes or public status pages. Delivery is at least once, with a stable event ID, bounded exponential backoff and at most ten attempts within three days. Deduplicate by event ID. A failed receiver does not stop checks; the monitor page shows failed deliveries.

Native Slack and Discord incoming webhooks have separate destination fields. Each channel receives its own delivery record and disables mention expansion. Email, when enabled, goes only to your verified linked account address and rechecks account authority before sending. Notification delivery can be delayed by the receiving provider.

Verify the Ed25519 signature before parsing or acting on the payload. Pin the trusted control-plane public key shown in the dashboard (also available from GET /v1/uptime/capabilities over verified HTTPS). Do not trust an arbitrary key just because it appears in a received header.

x-pipe-event-id: <event UUID>
x-pipe-signing-key: <hex Ed25519 public key>
x-pipe-signature: <hex Ed25519 signature>

signed bytes = UTF8("pipe-uptime/webhook/v1\n") + exact raw HTTP body

{ "protocol": "pipe-uptime/1", "event_id": "...",
  "monitor_id": "...", "monitor_name": "Production API",
  "incident_id": "...", "event": "down", "created_at": 0 }

The other event type is recovered. Preserve the raw body bytes for verification. Return a 2xx response only after safely accepting the event. Redirects are not followed. Pending notifications are cancelled when a monitor is paused, archived or reconfigured; an already-sent request cannot be recalled.

Public status and API access

Adding a public slug publishes /status/uptime/your-slug. It exposes only the monitor name, observed status, last round and daily sample counts. The target, account, billing and webhook remain private. Leave the slug blank for a private monitor. Do not put private information in a public monitor name.

The customer API is under /control-api/v1/uptime on the configured Pipe API origin. Scoped CLI or automation credentials need uptime.read or uptime.write, the appropriate personal/team grant, and live membership. Browser sessions use the existing authenticated dashboard proxy. Node poll/report endpoints are a separate signed protocol and are never forwarded through the customer proxy.

Creates and settings changes require a stable UUID request_id. Reuse the exact ID and payload after an uncertain response. The created monitor ID equals its creation request ID. Settings also require expected_revision; use GET /v1/uptime/monitors/ID/mutations/REQUEST_ID to reconcile a settings, pause or archive request. The browser retains only identity and a digest, not secret-bearing payloads. Reloading can confirm committed work; uncommitted changes may require re-entering their original settings. Subscription creation uses the same stable request-ID rule. Manage subscriptions at /v1/uptime/subscriptions; use their /policy, /cancel and /mutations/REQUEST_ID routes for changes and reconciliation.

Coverage and availability

The first release runs on explicitly approved trusted or managed Pipe nodes. Signed results identify the reporting node; they are not proof that an untrusted operator performed an honest measurement. Only qualified, healthy regions accept new monitors. Coverage is not automatically every Pipe PoP.

Probes apply a one-attempt-per-ten-seconds hostname safety limit. Multiple monitors of the same hostname can therefore produce unknown observations even when your plan has unused overall capacity. Use one representative health endpoint where possible. This release does not promise an uptime or notification-latency SLA.

Schema installation does not enable paid admission. Operator-approved plans, regional registration and live probe polling are separate launch gates. Cloudflare can remain the HTTP proxy; scheduling, probes, metering and results run on Pipe infrastructure.