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

Monitor types expose the settings relevant to their check:

• Name — A descriptive name for the monitor (max 100 characters)
• Interval — Check frequency for active pull checks (30-300 seconds, subject to plan limits)
• Timeout — Connection or request timeout where applicable (5-30 seconds)
• Alert Cooldown — Minimum time between repeated alerts (1-60 minutes)
• Failure Threshold — For multi-location HTTP/HTTPS checks, the number of selected locations that must fail before alerting

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

The worker extracts the hostname and port from the URL, then opens a raw TCP socket. The URL scheme makes the target parseable; it does not enable HTTP or TLS for the TCP check. If no port is present, the worker uses port 80.

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 resolve A, AAAA, MX, NS, TXT, and CNAME records and store the returned record set for inspection. A check is healthy when the hostname has at least one A record or CNAME; otherwise it is marked down.

Configuration

Enter the hostname to resolve, such as example.com. Record-specific expected-value assertions are not configurable.

SSL Certificate Monitors

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

Configuration

Enter the HTTPS URL to check. Certificate alert thresholds are fixed:

The check connects to the host, reads the peer certificate, records certificate details, and evaluates its expiration date.

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

Choose an expected interval of 1, 2, 5, 10, or 30 minutes; 1 hour; or 24 hours. A heartbeat is marked down when no ping has arrived within the selected interval. Heartbeat monitors do not add a separate grace period.

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, HTTP and HTTPS monitors can run from selected geographic locations. Starter supports up to two remote locations; Pro, Lifetime, Team, and Enterprise support all four.

When enabled:

• Checks run from the selected remote regions alongside the local check
• The configured failure threshold controls how many selected locations must fail before alerting
• Regional failures can produce DEGRADED status without declaring a full outage
• Response times and results are retained 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