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β
- Click "+ Add Monitor" on the dashboard
- Choose monitor type
- Fill in basic configuration
- 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β
-
Timeout errors
- Increase timeout value
- Check server response time
- Verify network connectivity
-
SSL/TLS errors
- Check certificate validity
- Verify certificate chain
- Consider disabling SSL verification temporarily
-
Authentication failures
- Verify credentials are correct
- Check if tokens have expired
- Confirm authentication method
-
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β
- Appropriate intervals - Don't check too frequently
- Timeout settings - Balance accuracy with performance
- Content validation - Use only when necessary
- 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:
- Configure a monitor with desired settings
- Save as template with variables
- Use template for new monitors
- Share templates with team members
π Best Practicesβ
Monitor Designβ
- Monitor critical user journeys - Not just infrastructure
- Use meaningful names - Make monitors easily identifiable
- Set appropriate intervals - Balance accuracy with resource usage
- Monitor dependencies - Include databases, APIs, third-party services
- Test edge cases - Include error scenarios and edge conditions
Performance Monitoringβ
- Set realistic thresholds - Based on historical performance
- Monitor from user perspective - Use external monitoring locations
- Include synthetic transactions - Test full user workflows
- Track trends - Look for gradual performance degradation
Monitor Strategyβ
- Monitor critical user journeys - Not just infrastructure
- Use meaningful names - Make monitors easily identifiable
- Set appropriate intervals - Balance accuracy with resource usage
- Group related services - Organize monitors logically
π For notification strategy, see Notification Best Practices
Security Considerationsβ
- Secure credentials - Use environment variables or secrets management
- Limited permissions - Use read-only credentials where possible
- Network security - Consider firewalls and IP restrictions
- Data privacy - Be careful with sensitive data in monitors
π Next Stepsβ
- Explore the Dashboard - Visualize your monitoring data
- Agent Management - Deploy and manage global monitoring agents
- Notification Setup - Configure alerts and notifications
- Use the API - Automate monitor management
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! π―