Monitors

Monitors are scheduled checks that verify your services are running correctly. Statly checks your endpoints from multiple global regions every 1-5 minutes.

Monitor Types

HTTP Monitors

The most common monitor type. Check web endpoints for expected responses.

Configuration:

Field	Description	Required
`name`	Display name for the monitor	Yes
`url`	Full URL including protocol	Yes
`method`	HTTP method (GET, POST, PUT, DELETE, PATCH, HEAD)	No (default: GET)
`expectedCode`	Expected HTTP status code	No (default: 200)
`timeout`	Max wait time in seconds (1-120)	No (default: 30)
`headers`	Custom headers as JSON object	No
`body`	Request body for POST/PUT	No

Example:

{
  "name": "Production API",
  "url": "https://api.example.com/health",
  "method": "GET",
  "expectedCode": 200,
  "timeout": 10,
  "headers": {
    "Authorization": "Bearer token123"
  }
}

TCP Monitors

Check that a port is accepting connections. Useful for databases, Redis, or custom services.

Configuration:

Field	Description	Required
`name`	Display name	Yes
`host`	Hostname or IP address	Yes
`port`	Port number (1-65535)	Yes
`timeout`	Max wait time in seconds	No (default: 10)

DNS Monitors

Verify DNS records are resolving correctly.

Configuration:

Field	Description	Required
`name`	Display name	Yes
`hostname`	Domain to query	Yes
`recordType`	A, AAAA, CNAME, MX, TXT, NS	Yes
`expectedValue`	Expected resolved value	No

Check Frequency

Monitors can run at different intervals based on your plan:

Plan	Minimum Interval
Free	5 minutes
Hobby	3 minutes
Pro	1 minute
Enterprise	30 seconds

Probe Regions

Checks run from AWS Lambda probes in multiple regions:

us-east-1 (N. Virginia)
us-west-2 (Oregon)
eu-west-1 (Ireland)
ap-northeast-1 (Tokyo)
ap-southeast-1 (Singapore)

A service is marked "down" only when checks fail from multiple regions. This prevents false positives from regional network issues.

Status States

Each monitor has one of these states:

State	Description	Color
`up`	All checks passing	Green
`degraded`	Slow responses or intermittent failures	Yellow
`down`	Consistent failures from multiple regions	Red
`paused`	Monitor is disabled	Gray

Heartbeats

Each check creates a heartbeat record with:

Timestamp
Status (up/down)
Response time (ms)
Region
Error message (if failed)

View heartbeat history in the monitor detail page or query via API.

Alerting

Configure alerts when monitors change state:

Email: Send to team members or custom addresses
Webhook: POST to your endpoint with signed payloads
Slack: Send to Slack channels via incoming webhooks
Discord: Post alerts to Discord channels
PagerDuty: Create and resolve incidents automatically
Microsoft Teams: Post to Teams channels
Opsgenie: Create and manage alerts
SMS: Send text messages via Twilio

See Notifications for detailed setup instructions.

Best Practices

Health Check Endpoints

Create dedicated health check endpoints for monitoring:

// Express.js example
app.get('/health', (req, res) => {
  // Check dependencies
  const dbHealthy = checkDatabase();
  const cacheHealthy = checkRedis();
 
  if (dbHealthy && cacheHealthy) {
    res.status(200).json({ status: 'healthy' });
  } else {
    res.status(503).json({ status: 'unhealthy' });
  }
});

Authentication

For authenticated endpoints, create a read-only monitoring token:

# Create in dashboard, then use in monitor config
{
  "headers": {
    "X-Monitoring-Token": "mon_xxx"
  }
}

Timeouts

Set appropriate timeouts based on your service:

Health checks: 5-10 seconds
API endpoints: 10-30 seconds
Heavy operations: 30-60 seconds

API

Manage monitors programmatically:

# List all monitors
curl -X GET "https://statly.live/api/v1/monitors" \
  -H "Authorization: Bearer sk_live_xxx"
 
# Create a monitor
curl -X POST "https://statly.live/api/v1/monitors" \
  -H "Authorization: Bearer sk_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{"name": "API", "url": "https://api.example.com/health"}'

See API Reference → Monitors for full documentation.

Incidents