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 sends an HTTP request using the configured method, headers, and body 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

Request Configuration

In addition to the schedule and expected status range, you can customize the request itself.

HTTP method

Choose from GET, HEAD, POST, PUT, PATCH, DELETE, or OPTIONS. Defaults to GET. Methods other than GET, HEAD, and OPTIONS may carry a request body.

Custom headers

Add any number of request headers (up to 50). Each header has a name, a value, and a “secret” toggle. When marked secret:

• The value is encrypted at rest using envelope encryption (AES-256-GCM)
• The value is masked in the dashboard and API responses
• The value is decrypted only inside the worker process at request time

To rotate a secret, type the new value into the field and save. To preserve a stored secret across edits without retyping, leave the value masked and save — the existing ciphertext is reused.

Request body

For POST, PUT, PATCH, and DELETE requests, add a body in either format:

• JSON: validated as parseable JSON; sent with Content-Type: application/json
• Raw: any text payload; you supply the Content-Type header

Bodies are limited to 64 KiB. A custom Content-Type header you set takes precedence over the body-derived default.

Response substring check

Optionally require the response body to contain a specific substring. The check is case-sensitive and operates on the first 256 KiB of the response. If the substring is missing, the monitor is marked Down with “Response missing expected text”.

Example: POST monitor with bearer token

URL:    https://api.example.com/probe
Method: POST
Headers:
  - Authorization: Bearer <token> (secret)
  - Accept: application/json
Body (JSON):
  {"source": "reoclo", "probe": "uptime"}
Expected: 200-200
Response must contain: ok

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
Substring check fails unexpectedly	Response body exceeds 256 KiB	The substring check only inspects the first 256 KiB; verify the substring appears earlier in the response

Next Steps

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