Uptime monitoring for websites, APIs and services
Monitor your websites, APIs and services from 28 regions. Get alerted the moment a check fails an assertion or exceeds your threshold.
Free to start, with a 14-day Starter trial and no card needed. Paid plans from $30/mo.
The monitor overview for Checkout API, checked every minute: 99.94% uptime, 4 of 6 regions failing, P50 231 ms, P95 4.39 s, with an uptime chart per minute and a P95 latency chart stacked by phase where TTFB jumps to about 4 seconds.
Trusted by teams who ship reliability
How it works
1. Declare
URL, method, headers, body and schedule. In the dashboard, the CLI or Terraform.2. Probe
Checkers in 28 regions run the request and record status, timing and body.3. Assert
Status code, headers, body and latency thresholds decide success, degraded or failed.4. Alert and publish
Notify Slack, PagerDuty or email. The status page reflects it without manual work.28 regions, three clouds
Probes run on Fly.io, Koyeb and Railway, so a provider incident never blinds you. Pick the regions your customers are in and see latency per region, not an average.
Per-region latency for the last check: London 4,388 ms, Amsterdam 4,102 ms, Paris 4,051 ms and Frankfurt 3,970 ms, all 503; Virginia 231 ms and San Jose 244 ms, both 200. 6 of the 28 regions are selected.
API monitoring with assertions
- authorization
- Bearer ••••••••
- content-type
- application/json
The request configuration and last result: a Bearer authorization header, assertions on status code 200 (failed, got 503), content-type contains json (passed) and body contains session_id (failed), degraded at 1,000 ms and timeout at 5,000 ms.
Any method, custom headers, a request body. Assert on status code, header and body, and set degraded and timeout thresholds so slow counts as a problem before down does.
Alerts where you already are
A failed assertion from one region is noise; from half your regions it is an alert. Route it to Slack, Discord, PagerDuty, Opsgenie, email, SMS or a webhook, with the failing requests attached.
Telegram, Google Chat, Microsoft Teams, WhatsApp, Grafana OnCall and ntfy are there too.
POST https://api.piedpiper.dev/v1/checkoutExpected status code 200, received 503
The alert as it reaches Slack, PagerDuty, email and a webhook: "Checkout API is failing", 503 Service Unavailable from four regions, "Expected status code 200, received 503", with a link to the failing checks.
Where the time went
The phase breakdown of the London check: DNS 12 ms, Connect 38 ms, TLS 61 ms, TTFB 4,265 ms, Transfer 12 ms. Only TTFB is above the 1,000 ms degraded threshold.
Every check records DNS, connect, TLS, time to first byte and transfer separately. A slow origin and a slow certificate handshake look the same in a total; they do not look the same here.
Monitoring as code
Declare monitors in HCL with the Terraform provider, or from the CLI in CI. Monitor changes get code-reviewed in the PR that ships the service they watch.
Already have monitors in the dashboard? Run openstatus terraform generate to bootstrap an HCL file from your workspace.
resource "openstatus_http_monitor" "checkout" {
name = "Checkout API"
url = "https://api.piedpiper.dev/v1/checkout"
method = "POST"
periodicity = "1m"
regions = ["fly-lhr", "fly-ams", "koyeb-fra", "fly-iad"]
status_code_assertions {
target = 200
comparator = "eq"
}
degraded_at = 1000
timeout = 5000
}
Private locations
docker run -d --name openstatus-probe \ --restart=always \ -e OPENSTATUS_KEY=os_•••••••• \ ghcr.io/openstatushq/private-location:latest
The docker run command that starts a probe from ghcr.io/openstatushq/private-location, an 8.5 MB image for arm64 and amd64, and two probes online: vpc-eu-west at 10.0.4.12 and office-berlin at 192.168.1.40.
Some services are not reachable from the internet. Run the probe in your VPC or office network with one container; results land in the same dashboard and status page. The probe dials out, so no inbound firewall rule is needed.
Every request, kept
Response logs with the timing breakdown, headers and body per region, for as long as your plan retains data.
The response-logs table for the check, one row per region with status, latency and a DNS, connect, TLS, TTFB and transfer bar. Headers and body are kept for every failed check and every request can be exported to OTLP.
Get started
Free to start, with a 14-day Starter trial and no card needed. Paid plans from $30/mo.Frequently asked questions
What is uptime monitoring?
Uptime monitoring is the practice of checking, on a fixed schedule and from outside your own network, whether a service is reachable and responding correctly. Checks typically run every 30 seconds to 10 minutes from probe locations around the world. Because the checks originate externally, they catch failures your internal dashboards cannot see — DNS problems, expired certificates, and regional outages.
How often should I check my service?
Match the frequency to the cost of the outage. Revenue-critical endpoints justify 30-second checks; internal tooling is usually fine at 5 or 10 minutes. Higher frequency shortens the time between a failure starting and you hearing about it, but consumes more of your check quota. openstatus supports 30s, 1m, 5m and 10m intervals depending on your plan.
What is the difference between uptime and availability?
Uptime is what your monitor measures: the proportion of checks that succeeded. Availability is what your users experienced, which includes degraded performance your checks may have passed. A service returning HTTP 200 in eight seconds is up but arguably not available. This is why thresholds matter alongside assertions — they let you count slow responses as degraded rather than healthy.
Can I monitor internal services?
Yes. Deploy a private location probe inside your network as an 8.5MB Docker container and it appears as another monitoring region in your dashboard. The probe reaches out to openstatus, so no inbound firewall rule is needed. You can run as many private locations as you like across different VPCs or networks.
How do I monitor a REST or GraphQL API?
Create an HTTP monitor pointing at the endpoint, choose the method, and add any headers your API needs for authentication. For GraphQL, send a POST with the query in the body. Then add assertions on the status code, response headers, or body content so the monitor verifies the response is correct rather than merely present, and set a threshold so slow responses register as degraded.
How much does uptime monitoring cost?
The free Hobby plan includes one monitor at a 10-minute interval with no credit card. Paid plans start at $30/month for Starter (20 monitors, 1-minute checks, 6 regions per monitor), $100/month for Pro (50 monitors, 30-second checks, all 28 regions), and $500/month for Scale. Annual billing gives you two months free.
How many regions should I monitor from?
Start with 3-5 regions covering your main user geographies. More regions provide better global coverage but use more check quota. For critical services, monitor from all major regions (North America, Europe, Asia) to catch regional issues quickly.
Why monitor from multiple cloud providers instead of just one?
If your service runs on AWS and your monitoring also runs on AWS, you won't detect AWS-wide outages or network issues affecting AWS connectivity. Using Fly.io, Koyeb, and Railway ensures monitoring independence from your infrastructure provider.
What's the difference between frequency settings?
Frequency determines how often we check your service (e.g., every 30 seconds, 1 minute, 5 minutes, 10 minutes). Higher frequency (30s) catches issues faster but uses more checks. Lower frequency (10m) is sufficient for non-critical services and conserves quota.
Can uptime monitoring trigger my status page automatically?
Yes, you can configure monitors to automatically update your status page based on monitoring results. When assertions fail or thresholds are exceeded, the status page can reflect degraded or down status without manual intervention.
How do thresholds and assertions work together?
Assertions validate response correctness (status code, headers, body content) while thresholds define performance boundaries (degraded latency, timeout). Both can trigger alerts - assertions catch functional failures, thresholds catch performance degradation.
What types of API endpoints can I monitor?
You can monitor any HTTP/HTTPS endpoint including REST APIs, GraphQL APIs, webhooks, and third-party service endpoints. openstatus supports all HTTP methods (GET, POST, PUT, DELETE, etc.) and custom headers for authentication.
Can I manage monitors with Terraform?
Yes. The openstatus Terraform provider manages HTTP, TCP, DNS and ICMP monitors — with headers, assertions and thresholds — plus notification channels, status pages and private locations. Monitors live in HCL next to the rest of your infrastructure and go through the same plan-and-apply lifecycle. Run openstatus terraform generate to bootstrap an HCL file from an existing workspace.
Can I run private monitoring locations in different networks?
Yes, you can deploy as many private location probes as needed across different networks, VPCs, or regions. Each gets its own API key and appears as a separate monitoring region in your dashboard. The Docker image is only 8.5MB and supports ARM64 and AMD64.