Uptime monitoring for websites and APIs
Monitor website and API uptime from around the world. Get instant downtime alerts via Slack, email and SMS. Free, open-source uptime monitoring
+----------------+
| Service to be |
| Monitored |
+----------------+
▲
|
| (Network Latency/Failures)
|
+-----+-------+ +-----+-------+ +-----+-------+
| Monitoring | | Monitoring | | Monitoring |
| Node (USA) | | Node (EU) | | Node (Asia) |
+-----+-------+ +-----+-------+ +-----+-------+
| | |
|---------------|-----------------|
▼ ▼ ▼
+------------------------------------------------+
| openstatus |
| |
| - Sends automated requests (e.g., pings or |
| HTTP checks) from all nodes at set intervals |
| - Records response time and success/failure |
| - Compares results from different nodes |
| - If a failure or a slow response is detected, |
| it triggers an alert. |
+------------------------------------------------+
|
| (Alerts: Email, SMS, Slack, etc.) 🔔
|
+-----+-----+
| Your Team |
+-----------+
Why uptime monitoring is important?
Uptime monitoring is your first line of defense to ensure your service is available for your customers. By monitoring your service from multiple regions around the world, you can be sure that your customers are able to reach your service.
Uptime Dashboard
Response Logs
Why choose openstatus for uptime monitoring?
Global Monitoring
You can monitor your services from multiple regions around the world. We currently have our probes deployed in 28 regions.
Check all regions in the global speed checker.
Multi Cloud
You should avoid monitoring your services from the same cloud providers you use for those services. That's why our probes are deployed across three different cloud providers:
- Fly.io
- Koyeb
- Railway
API Monitoring
Monitor any HTTP/HTTPS endpoint including REST APIs, GraphQL APIs, webhooks, and third-party service endpoints. Openstatus supports all HTTP methods and custom headers for authentication.
Assertions
Validating your response can be important. You can do status code, header or body text assertions. Read more in the docs.
Thresholds
You can set a degraded at and timeout threshold whenever required. We will send you a notification whenever the responses exceed the thresholds.
Open Telemetry
When needed, you can export to your OTLP endpoint the metrics for every request we do. Access the data and set yourself an alert channel in Grafana, Honeycomb etc. Read more in our guide.
Notification channels
Set different notification channels and get notified whenever a not satisfying your assertions or are exceeding the thresholds.
We support:
- Socials: Slack, Discord, Telegram Bot
- Direct: Email, SMS
- Incident Management: OpsGenie, PagerDuty
- Custom: Webhook, Ntfy
Status Pages
Automatically update your status page based on your uptime monitoring results. Push reports and communicate with your users during incidents. You can choose to share response details on your status page. Read more about status pages.
Monitoring as Code
The best way to version your monitor changes is via the openstatus CLI and its YAML config. Additionally, we provide a Terraform Provider.
# yaml-language-server: $schema=https://www.openstatus.dev/schema.json
uptime-monitor:
name: "Graphql"
description: "GitHub GraphQL API"
frequency: "10m"
active: true
regions:
- iad
- ams
- syd
- jnb
- gru
retry: 3
kind: http
request:
url: https://api.github.com/graphql
method: POST
headers:
User-Agent: OpenStatus
Authorization: Bearer YOUR_TOKEN_HERE
body: |
{
"query": "query { viewer { login }}"
}
Once set, apply your changes via CLI:
openstatus monitors apply
Check our GitHub repository to see the YAML templates of how to monitor MCP, GraphQL,... endpoints. We also provide a simple GitHub Action to run it in your CI/CD.
Private Locations
Sometimes the services you want to monitor are not accessible from the outside. Simply deploy our probes to your favorite cloud provider, your own server or on your own virtual private cloud (VPC).
The docker image is only 8.5MB small and should easily fit on your infrastructure whether ARM64 or AMD64.
docker pull ghcr.io/openstatushq/private-location:latest
docker run -d \
--name openstatus-private-location \
--restart=always \
-e OPENSTATUS_KEY=$OPENSTATUS_KEY \
ghcr.io/openstatushq/private-location:latest
You can read more here:
Status Page Monitors
Frequently asked questions
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.
Should I use YAML with CLI or Terraform for monitoring as code?
Use YAML + CLI for simplicity and if you're not already using Terraform. It's lightweight and easy to get started. Choose Terraform if you're managing infrastructure as code and want to integrate monitoring into your existing Terraform workflows for unified state management.
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.
Check your website's latency
Global Speed Checker