Creating Monitors

Monitors are the core of PixoMonitor. They regularly check your services and alert you when something goes wrong. This guide covers all 10 monitor types and how to configure each one.

Monitor Types Overview

Common Settings

All monitor types share these configuration options:

• Name — A descriptive name for the monitor (max 100 characters)
• Interval — How often to run checks (30-300 seconds, depending on plan)
• Timeout — How long to wait before considering a check failed (5-30 seconds)
• Alert Cooldown — Minimum time between repeated alerts (1-60 minutes)
• Failure Threshold — Number of consecutive failures before alerting (1-10)

HTTP/HTTPS Monitors

HTTP monitors check that a URL returns a successful response. This is the most common monitor type for websites and APIs.

Configuration Options

Basic HTTP Monitor

https://api.example.com/health

JSON Response Validation

For API endpoints that return JSON, you can validate specific fields:

• Expected JSON Path: $.status or $.data.healthy
• Expected JSON Value: "ok" or true

Example: To verify that {"status": "healthy"} is returned, set:

• JSON Path: $.status
• JSON Value: healthy

TCP Monitors

TCP monitors check that a port is open and accepting connections. Use these for databases, mail servers, and other non-HTTP services.

Configuration Options

Common TCP Monitoring Use Cases

• PostgreSQL — Port 5432
• MySQL — Port 3306
• Redis — Port 6379
• MongoDB — Port 27017
• SMTP — Port 25 or 587
• SSH — Port 22

DNS Monitors

DNS monitors verify that DNS records are resolving correctly. Use these to detect DNS hijacking or configuration issues.

Configuration Options

Example DNS Monitor

To verify that example.com resolves to 93.184.216.34:

1. Set hostname to example.com
2. Set record type to A
3. Set expected value to 93.184.216.34

SSL Certificate Monitors

SSL monitors track certificate expiration and alert you before certificates expire. This helps prevent "Not Secure" warnings for your users.

Configuration Options

How It Works

1. PixoMonitor connects to your HTTPS endpoint
2. Retrieves the SSL certificate details
3. Checks the expiration date
4. Alerts when fewer than the warning threshold days remain

Heartbeat Monitors

Heartbeat monitors work in reverse — your service pings PixoMonitor instead of PixoMonitor pinging your service. This is perfect for cron jobs, scheduled tasks, and batch processes.

How Heartbeat Monitors Work

1. Create a heartbeat monitor to get a unique URL
2. Add a request to that URL at the end of your script
3. If PixoMonitor doesn't receive a ping within the expected interval, you're alerted

Configuration Options

Example: Monitoring a Cron Job

For a backup script that runs daily at 2 AM:

1. Create a heartbeat monitor with a 24-hour interval
2. Get the unique heartbeat URL (e.g., https://pixomonitor.com/api/heartbeat/abc123)
3. Add a curl request at the end of your backup script:

#!/bin/bash
# backup.sh
pg_dump mydb > /backups/mydb.sql
curl -fsS --retry 3 https://pixomonitor.com/api/heartbeat/abc123

Domain Expiry Monitors

Domain expiry monitors track when your domain names will expire. Get alerts before you lose critical domains.

Configuration Options

How It Works

PixoMonitor queries WHOIS data to check the domain expiration date and alerts you when the domain is approaching expiration.

Transaction Monitors

Transaction monitors (also called synthetic monitoring) run multi-step browser tests. Use these to verify user workflows like login, checkout, or sign-up processes.

Available Actions

Example: Login Flow

To verify users can log in to your application:

[
  { "action_type": "navigate", "value": "https://app.example.com/login" },
  { "action_type": "type", "selector": "#email", "value": "test@example.com" },
  { "action_type": "type", "selector": "#password", "value": "testpassword" },
  { "action_type": "click", "selector": "button[type=submit]" },
  { "action_type": "wait", "value": "2000" },
  { "action_type": "assert_text", "selector": ".welcome", "value": "Welcome" }
]

Cron Job Monitors

Cron job monitors verify that scheduled tasks run on their expected schedule. Unlike heartbeat monitors, you define the expected cron expression upfront.

Configuration Options

Cron Expression Format

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of month (1 - 31)
│ │ │ ┌───────────── month (1 - 12)
│ │ │ │ ┌───────────── day of week (0 - 6, Sunday = 0)
│ │ │ │ │
* * * * *

Common Cron Expressions

WebSocket Monitors

WebSocket monitors verify that WebSocket endpoints are accessible and responding correctly.

Configuration Options

How WebSocket Monitoring Works

1. Establishes a WebSocket connection
2. Optionally sends a configured message
3. Optionally verifies the response matches expectations
4. Considers the check successful if connection succeeds

Advanced Features

Multi-Location Monitoring

On paid plans, you can enable checks from multiple geographic locations. This helps detect region-specific outages and reduces false positives.

When enabled:

• Checks run from multiple regions simultaneously
• A monitor is only considered down if multiple locations report failures
• Response times are reported per-location

Anomaly Detection

PixoMonitor can automatically detect performance anomalies by learning your service's normal response time patterns.

• Sensitivity — How many standard deviations from the mean trigger an anomaly (1.0-5.0)
• Baseline — Calculated from 7 days of data, requires at least 100 samples

Alert Cooldown

To prevent alert fatigue, configure a cooldown period between repeated alerts:

• Alert Cooldown Minutes — Minimum time between alerts (1-60 minutes)
• While in cooldown, PixoMonitor still tracks failures but doesn't send duplicate alerts

Escalation Policies

Link monitors to escalation policies to automatically escalate unacknowledged incidents to additional team members. See the Escalation Policies guide for details.

Best Practices

1. Use descriptive names — Make it easy to identify what's being monitored
2. Set appropriate intervals — More critical services warrant more frequent checks
3. Configure failure thresholds — Avoid false alarms from temporary issues
4. Monitor health endpoints — Create dedicated /health endpoints for monitoring
5. Use multiple monitor types — HTTP for the app, TCP for the database, SSL for certificates
6. Test alert channels — Verify notifications work before relying on them