Monitoring & Uptime

Monitors perform periodic HTTP health checks against your endpoints and track uptime over time. They can be linked to applications, servers, or used standalone to monitor any URL. Monitor results feed into status page components and trigger notifications when things go down or recover.

Creating a Monitor

1. Navigate to Monitors in the sidebar
2. Click Create Monitor
3. Configure the check:
   • Name: descriptive label (e.g., “API Health Check”)
   • URL: the base URL to check (e.g., https://api.example.com)
   • Check path: path appended to the URL (default: /)
   • Check interval: how often to check (10 seconds to 1 hour)
   • Timeout: how long to wait for a response (1-120 seconds)
   • Expected status range: HTTP status codes considered healthy (default: 200-399)
4. Optionally link to an application or server
5. Click Create

The monitor starts checking immediately.

How Checks Work

Every check interval, Reoclo makes an HTTP GET request to your endpoint:

1. Constructs the full URL: {base URL}{check path}
2. Sends the request with the configured timeout
3. Measures response time (latency)
4. Evaluates the result:

Result	Status	Meaning
HTTP status in expected range, latency under 5 seconds	Up	Healthy
HTTP status in expected range, latency over 5 seconds	Degraded	Responding but slow
HTTP status outside expected range	Down	Unhealthy
Timeout or connection error	Down	Unreachable

Each check is recorded as a check event with the timestamp, status, latency, and HTTP status code.

Monitor States

State	Checks running	Description
Active	Yes	Monitor is checking on schedule
Paused	No	Temporarily stopped, can be resumed
Deleted	No	Soft-deleted, hidden from lists

Pause a monitor to temporarily stop checks without losing configuration. Resume to start checks again immediately.

Uptime Tracking

Reoclo tracks uptime on a daily basis. For each day, it records:

• Total checks performed
• Checks that returned Up
• Checks that returned Degraded
• Checks that returned Down
• Overall uptime percentage: (checks_ok / checks_total) * 100

This data powers the 90-day uptime bars on status pages.

Configuration Options

Setting	Default	Range	Description
Check interval	60 seconds	10s - 1 hour	Time between checks
Timeout	30 seconds	1 - 120 seconds	Max wait for response
Expected status min	200	100 - 599	Lowest acceptable HTTP status
Expected status max	399	100 - 599	Highest acceptable HTTP status
Check path	/	max 500 chars	Path appended to base URL

Status Range Examples

Range	Accepts	Use case
200-200	Only 200 OK	Strict health check
200-299	All 2xx success codes	Standard API monitoring
200-399	2xx and 3xx (default)	Web apps with redirects

Linking to Resources

Monitors can be linked to:

• An application: track the health of a deployed app
• A server: track the health of a server endpoint
• Nothing (standalone): monitor any external URL

Linked monitors show up on the application or server detail page. They can also be used as the source for status page components, so the component status automatically reflects the monitor’s health.

Status Page Integration

When you add a component to a status page, you can set its source to a monitor. The component status automatically maps from the monitor:

Monitor status	Component status
Up	Operational
Degraded	Degraded Performance
Down	Major Outage
Paused	Unknown

The 90-day uptime history on status pages is built from daily check aggregations.

Consecutive Failures

The monitor tracks consecutive failures. This counter:

• Increments on each Down or Degraded check
• Resets to 0 on a successful (Up) check
• Can be used by notifications to avoid alerting on single transient failures

Examples

Basic health check

URL: https://api.example.com
Path: /health
Interval: 60 seconds
Expected: 200-200

Checks https://api.example.com/health every minute, expecting exactly 200 OK.

Web app with redirects

URL: https://myapp.com
Path: /
Interval: 120 seconds
Expected: 200-399

Checks the homepage every 2 minutes, accepting any successful or redirect response.

Aggressive monitoring for critical service

URL: https://payments.example.com
Path: /api/status
Interval: 10 seconds
Timeout: 5 seconds
Expected: 200-200

Checks every 10 seconds with a tight 5-second timeout for a critical payment service.

Troubleshooting

Issue	Cause	Fix
Monitor shows Down but site works	Expected status range too narrow	Widen the range (e.g., 200-399)
Monitor shows Degraded	Response time over 5 seconds	Optimize the endpoint or check a lighter path
Checks not running	Monitor is paused	Resume the monitor
Latency seems high	Check path returns large response	Use a lightweight health endpoint

Next Steps

• Status Pages to display uptime publicly
• Notifications to get alerted on downtime
• Custom Domains which have built-in DNS and SSL monitoring