Skip to main content

Monitors

Monitors are the core of CuliUptime - they define what services to check, how often to check them, and what constitutes a healthy response. This guide covers everything you need to know about creating and managing monitors.

🎯 Monitor Types​

HTTP/HTTPS Monitors βœ… Available​

Monitor web endpoints, APIs, and web applications.

Perfect for:

  • Websites and web applications
  • REST APIs and web services
  • CDN endpoints
  • Load balancer health checks

Configuration Options:

URL: https://api.example.com/health
Method: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS
Expected Status: 200, 2xx, 3xx, specific codes
Timeout: 5-60 seconds
Follow Redirects: Yes/No (max 10 redirects)

Future Monitor Types (v0.2.0+) 🚧 Coming Soon​

The following monitor types are planned for future CuliUptime releases:

TCP Monitors​

Check if TCP ports are accessible and responding.

Will be perfect for:

  • Database servers (MySQL, PostgreSQL, MongoDB)
  • Mail servers (SMTP, IMAP, POP3)
  • Custom TCP services
  • Game servers

ICMP Ping Monitors​

Test network connectivity and response times.

Will be perfect for:

  • Server reachability tests
  • Network infrastructure monitoring
  • Basic connectivity verification
  • Latency measurements

DNS Monitors​

Verify DNS resolution and check specific DNS records.

Will be perfect for:

  • Domain resolution verification
  • DNS server health
  • DNS propagation monitoring
  • Record change detection

UDP Monitors​

Monitor UDP-based services and applications.

Will be perfect for:

  • DNS servers
  • DHCP servers
  • Game servers
  • Custom UDP applications

πŸ“… Release Timeline: These monitor types are actively under development and planned for CuliUptime v0.2.0+. Follow our GitHub repository for updates!

βž• Creating Monitors​

Quick Setup​

  1. Click "+ Add Monitor" on the dashboard
  2. Choose monitor type
  3. Fill in basic configuration
  4. Click "Create Monitor"

Step-by-Step HTTP Monitor Creation​

Basic Information​

Monitor Name: My Website
Description: Main website monitoring (optional)
URL: https://www.example.com

HTTP Configuration​

Method: GET
Expected Status Codes: 200-299 (or specific codes like 200,201,204)
Follow Redirects: βœ… Enabled
Max Redirects: 5
Timeout: 30 seconds

Advanced Options​

Custom Headers:
User-Agent: CuliUptime/1.0
Authorization: Bearer your-token-here

Request Body (for POST/PUT):
Content-Type: application/json
Body: {"health": "check"}

SSL Verification: βœ… Enabled
Ignore SSL Errors: ❌ Disabled (enable only if needed)

Content Validation​

Expected Content: "status: ok" (optional)
Content Must Not Contain: "error" (optional)
JSON Path Validation: $.status == "healthy" (optional)
Response Time Threshold: 2000ms

Scheduling​

Check Interval: 5 minutes
Retry Attempts: 3
Retry Interval: 1 minute
Locations: US-East, EU-West, Asia-Southeast

πŸ’‘ Learn more about agent management in our Agent Management Guide

βš™οΈ Advanced Configuration​

Authentication Methods​

Basic Authentication​

Type: Basic Auth
Username: your_username
Password: your_password

Digest Authentication​

Type: Digest Auth
Username: your_username
Password: your_password

Bearer Token​

Type: Bearer Token
Token: your_jwt_token_here

Custom Headers​

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
X-API-Key: your_api_key_here
X-Custom-Header: custom_value

Request Body Configuration​

JSON Payload​

{
"service": "health-check",
"timestamp": "{{timestamp}}",
"source": "culiuptime"
}

Form Data​

username=test&password=secret&action=login

Raw Text​

Custom raw request body content

Response Validation​

Status Code Validation​

  • Single code: 200
  • Range: 200-299
  • Multiple codes: 200,201,204,301
  • Exclude codes: !404,!500

Content Matching​

  • Contains: Response must contain specific text
  • Not contains: Response must not contain specific text
  • Regex: Use regular expressions for complex patterns
  • JSON Path: Validate JSON responses: $.status == "ok"
  • XPath: Validate XML/HTML responses

Performance Thresholds​

  • Response time: Maximum acceptable response time
  • Size limits: Minimum/maximum response size
  • Header validation: Check for specific response headers

🌍 Global Monitoring​

Multi-Location Checking​

Deploy monitors from multiple geographic locations to:

  • Reduce false positives from network issues
  • Test global CDN performance
  • Verify regional accessibility
  • Meet compliance requirements

Available Locations (Cloud Service)​

  • πŸ‡ΊπŸ‡Έ US-East (Virginia)
  • πŸ‡ΊπŸ‡Έ US-West (California)
  • πŸ‡ͺπŸ‡Ί EU-West (Ireland)
  • πŸ‡ͺπŸ‡Ί EU-Central (Frankfurt)
  • 🌏 Asia-Southeast (Singapore)
  • 🌏 Asia-Northeast (Tokyo)

Consensus Monitoring​

  • Majority consensus: Service marked down only if majority of locations fail
  • Any location: Service marked down if any location fails
  • All locations: Service marked down only if all locations fail
  • Custom threshold: Define specific number of failed locations

πŸ“Š Monitor Status & Metrics​

Status Types​

  • 🟒 Online - All checks passing
  • πŸ”΄ Offline - Service not responding or failing validation
  • 🟑 Degraded - Some checks failing but service partially available
  • βšͺ Pending - First check in progress
  • πŸ”΅ Paused - Monitoring temporarily disabled
  • ⚫ Maintenance - Scheduled maintenance mode

Key Metrics​

  • Current Status - Current up/down state
  • Uptime Percentage - Availability over time periods
  • Average Response Time - Performance metrics
  • Performance Grade - Automated A/B/C/F rating based on uptime and response time
  • Total Downtime - Cumulative offline time
  • Incident Count - Number of downtime events
  • MTTD - Mean Time To Detection
  • MTTR - Mean Time To Recovery

Performance Grading System​

CuliUptime automatically assigns performance grades to help you quickly assess service quality:

  • 🟒 Grade A (90-100%) - Excellent performance (>99% uptime, <500ms avg response)
  • 🟑 Grade B (80-89%) - Good performance (95-99% uptime, <1000ms avg response)
  • 🟠 Grade C (70-79%) - Fair performance (90-95% uptime, <2000ms avg response)
  • πŸ”΄ Grade F (<70%) - Poor performance (<90% uptime or >2000ms avg response)

Grading Criteria:

  • Uptime Weight: 70% of grade calculation
  • Response Time Weight: 30% of grade calculation
  • Calculation Period: Based on last 30 days of data
  • Updates: Recalculated every 24 hours

Historical Data​

  • Response time trends - Performance over time
  • Uptime charts - Visual availability representation
  • Incident timeline - Detailed downtime history
  • Performance analytics - Peak, average, and trend analysis

πŸ”” Notification Integration​

Monitors can trigger various types of notifications when issues are detected. For complete notification configuration and management, see our dedicated Notification Guide.

Quick Reference:

  • Downtime notifications - Service becomes unavailable
  • Recovery notifications - Service returns to healthy state
  • Performance notifications - Response time exceeds threshold
  • Performance notifications - Response time threshold alerts

πŸ“ Configure Notifications β†’

🏷️ Organization & Management​

Monitor Groups (Coming Soon)​

Organize related monitors:

  • By Environment - Production, Staging, Development
  • By Team - Frontend, Backend, DevOps
  • By Application - User-facing, Internal APIs
  • By Criticality - Critical, Important, Nice-to-have

Tags and Labels​

Use tags for organization and filtering:

Tags: [production, api, critical, team-backend]
Environment: production
Owner: backend-team
SLA: 99.9%

Bulk Operations​

  • Select multiple monitors - Checkbox selection
  • Bulk edit - Apply changes to multiple monitors
  • Bulk pause/resume - Temporary disable monitoring
  • Bulk delete - Remove multiple monitors
  • Export/import - Backup and migrate configurations

πŸ”§ Maintenance & Troubleshooting​

Maintenance Mode (Future Version)​

Maintenance mode features are planned for future CuliUptime versions:

  • Planned for v0.2.0+ - Schedule maintenance windows
  • Notification pausing - Temporarily disable notifications
  • Current workaround - Manually pause monitors during maintenance

Troubleshooting Failed Monitors​

Common Issues​

  1. Timeout errors

    • Increase timeout value
    • Check server response time
    • Verify network connectivity
  2. SSL/TLS errors

    • Check certificate validity
    • Verify certificate chain
    • Consider disabling SSL verification temporarily
  3. Authentication failures

    • Verify credentials are correct
    • Check if tokens have expired
    • Confirm authentication method
  4. Content validation failures

    • Review expected vs actual content
    • Check for case sensitivity
    • Verify regex patterns

Debug Information​

Each failed check includes:

  • Error message - Specific failure reason
  • Response headers - Server response headers
  • Response body - Server response content (if available)
  • Timing information - Connection and response times
  • SSL details - Certificate information

Monitor Performance​

Optimization Tips​

  1. Appropriate intervals - Don't check too frequently
  2. Timeout settings - Balance accuracy with performance
  3. Content validation - Use only when necessary
  4. Location selection - Choose relevant geographic regions

Resource Usage​

  • Check frequency - Higher frequency uses more resources
  • Timeout values - Longer timeouts may delay other checks
  • Content validation - Processing large responses takes time
  • Multiple locations - Each location consumes check quota

πŸ“‹ Monitor Templates​

Pre-configured Templates​

Speed up monitor creation with templates:

Website Template​

Name: "{{site_name}} Website"
URL: "https://{{domain}}"
Method: GET
Expected Status: 200-299
Timeout: 30s
Content Contains: "<title>"
Check Interval: 5 minutes

API Health Check Template​

Name: "{{service_name}} API Health"
URL: "https://{{api_url}}/health"
Method: GET
Expected Status: 200
Timeout: 10s
JSON Path: "$.status == 'healthy'"
Check Interval: 2 minutes

Database Health API Template (v0.1.0 Compatible)​

Name: "{{db_name}} Database Health"
URL: "https://{{api_url}}/db/health"
Method: GET
Expected Status: 200
Timeout: 15s
JSON Path: "$.database_status == 'healthy'"
Check Interval: 5 minutes

Future Database Connection Template (v0.2.0+)​

Name: "{{db_name}} Database"
Type: TCP
Host: "{{db_host}}"
Port: "{{db_port}}"
Timeout: 15s
Check Interval: 5 minutes

Custom Templates​

Create your own templates for consistent monitoring:

  1. Configure a monitor with desired settings
  2. Save as template with variables
  3. Use template for new monitors
  4. Share templates with team members

πŸ“Š Best Practices​

Monitor Design​

  1. Monitor critical user journeys - Not just infrastructure
  2. Use meaningful names - Make monitors easily identifiable
  3. Set appropriate intervals - Balance accuracy with resource usage
  4. Monitor dependencies - Include databases, APIs, third-party services
  5. Test edge cases - Include error scenarios and edge conditions

Performance Monitoring​

  1. Set realistic thresholds - Based on historical performance
  2. Monitor from user perspective - Use external monitoring locations
  3. Include synthetic transactions - Test full user workflows
  4. Track trends - Look for gradual performance degradation

Monitor Strategy​

  1. Monitor critical user journeys - Not just infrastructure
  2. Use meaningful names - Make monitors easily identifiable
  3. Set appropriate intervals - Balance accuracy with resource usage
  4. Group related services - Organize monitors logically

πŸ“ For notification strategy, see Notification Best Practices

Security Considerations​

  1. Secure credentials - Use environment variables or secrets management
  2. Limited permissions - Use read-only credentials where possible
  3. Network security - Consider firewalls and IP restrictions
  4. Data privacy - Be careful with sensitive data in monitors

πŸš€ Next Steps​

Start with simple HTTP monitors and gradually add complexity as you become more familiar with the system. Remember: effective monitoring is about finding the right balance between coverage and maintainability! 🎯