diff --git a/communicate/alerts/best-practices.mdx b/communicate/alerts/best-practices.mdx deleted file mode 100644 index 5e6c892e..00000000 --- a/communicate/alerts/best-practices.mdx +++ /dev/null @@ -1,736 +0,0 @@ ---- -title: 'Alerting Best Practices' -description: 'Proven strategies and patterns for effective alerting, incident response, and alert fatigue prevention in Checkly monitoring implementations.' -sidebarTitle: 'Best Practices' -canonical: 'https://www.checklyhq.com/docs/communicate/alerts/best-practices/' ---- - - - -Effective alerting requires careful balance between comprehensive coverage and alert fatigue prevention. These proven practices help you build reliable, actionable alerting that improves incident response without overwhelming your team. - -## Alert Strategy Fundamentals - -### The Alert Quality Pyramid -Build alerting that prioritizes signal over noise: - -```mermaid -graph TD - A[Critical Alerts - Immediate Action] --> B[Warning Alerts - Investigate Soon] - B --> C[Info Alerts - Monitor Trends] - C --> D[Debug Logs - Historical Analysis] - - style A fill:#ff6b6b - style B fill:#ffa500 - style C fill:#4ecdc4 - style D fill:#95a5a6 -``` - - - -**Immediate Action Required** -- Customer-impacting outages -- Security breaches -- Data loss scenarios -- Payment system failures -- Always page on-call engineer - - - -**Investigate Within Hours** -- Performance degradation -- Non-critical service failures -- Approaching resource limits -- SSL certificate expiration -- Business hours response acceptable - - - -**Monitor and Trend** -- Successful recoveries -- Planned maintenance -- Performance improvements -- Capacity planning data -- No immediate action needed - - - -**Historical Analysis** -- Detailed performance metrics -- Trace data and logs -- User behavior analytics -- System health indicators -- Available for investigation - - - -### Alert Criticality Matrix -Use a systematic approach to determine alert priority: - -| Impact | Customer Facing | Internal Only | -|--------|----------------|---------------| -| **Complete Outage** | P1 - Page immediately | P2 - Alert within 15 min | -| **Significant Degradation** | P1 - Page immediately | P2 - Alert within 30 min | -| **Minor Issues** | P2 - Alert within 1 hour | P3 - Daily summary | -| **Performance Variance** | P3 - Monitor trends | P4 - Log only | - -## Escalation Strategy Best Practices - -### Run-Based vs Time-Based Escalation -Choose the right strategy for different scenarios: - - - -**Best for stable systems:** -```yaml -Configuration: - Trigger: 2-3 consecutive failures - Use cases: - - Reliable APIs with clear success/failure - - Services with predictable behavior - - Well-tested applications - - Internal microservices -``` - - - -**Best for dynamic systems:** -```yaml -Configuration: - Trigger: 5-15 minutes of failures - Use cases: - - High-frequency checks (every 1-2 minutes) - - Auto-scaling applications - - Third-party dependencies - - Rate-limited services -``` - - - -### Frequency-Specific Configurations -Tailor escalation to check frequency: - -```yaml -# High frequency (1-2 minutes) -High_Frequency_Config: - Strategy: Time-based (10 minutes) - Reasoning: Multiple runs provide enough signal - Location_Threshold: 67% (avoid regional noise) - Retries: Minimal (2 attempts, 30s apart) - -# Standard frequency (5-15 minutes) -Standard_Config: - Strategy: Run-based (2 failures) - Reasoning: Each run is significant - Location_Threshold: 50% (balanced sensitivity) - Retries: Moderate (3 attempts, exponential) - -# Low frequency (30+ minutes) -Low_Frequency_Config: - Strategy: Run-based (1 failure) - Reasoning: Every failure is important - Location_Threshold: 33% (high sensitivity) - Retries: Aggressive (5 attempts, exponential) -``` - -## Retry Strategy Optimization - -### Intelligent Retry Configuration -Match retry strategies to failure patterns: - - - -**Fixed interval retries** -```yaml -Strategy: Fixed -Interval: 10 seconds -Max_Retries: 3 -Use_Case: DNS, connectivity issues -``` - - - -**Linear backoff** -```yaml -Strategy: Linear -Base_Interval: 15 seconds -Max_Retries: 4 -Use_Case: Service restarts, deployments -``` - - - -**Exponential backoff** -```yaml -Strategy: Exponential -Base_Interval: 5 seconds -Max_Retries: 3 -Use_Case: API rate limits, overload -``` - - - -### Location-Based Retry Logic -Optimize retry behavior based on deployment architecture: - -```yaml -# Global service (CDN, SaaS) -Global_Service_Retries: - Same_Location: false - Reasoning: Different location may succeed - Locations: 6+ worldwide - Threshold: 50% must fail - -# Regional service (data center specific) -Regional_Service_Retries: - Same_Location: true - Reasoning: Issue likely location-specific - Locations: 2-3 regional - Threshold: 67% must fail - -# Single location service -Single_Location_Retries: - Same_Location: true - Reasoning: Only one location available - Locations: 1 - Threshold: 100% (obviously) -``` - -### Network vs Application Error Handling -Distinguish between network and application failures: - -```yaml -Network_Retry_Configuration: - Enabled: true - Retry_On_Errors: - - ECONNRESET (connection reset) - - ENOTFOUND (DNS failure) - - ETIMEDOUT (timeout) - - ECONNREFUSED (connection refused) - - Skip_On_HTTP_Status: true - Reasoning: "4xx/5xx are application errors, not network issues" - -Application_Error_Handling: - HTTP_4xx: No retry (client error) - HTTP_5xx: No retry (server error, likely persistent) - Assert_Failures: No retry (application logic issue) - -Benefits: - - Reduces noise from transient network issues - - Focuses alerts on real application problems - - Improves signal-to-noise ratio -``` - -## Channel Organization Strategies - -### Multi-Tier Alert Routing -Structure alert channels for effective incident response: - -```yaml -# Tier 1: Critical Production Alerts -Critical_Production: - Checks: Customer-facing services with "critical" tag - Escalation: Immediate on first failure - Channels: - - PagerDuty: Primary on-call rotation - - SMS: Primary and backup engineers - - Slack: #production-alerts channel - - Phone: For P1 incidents only - - Business_Hours: 24/7 coverage - Response_SLA: 5 minutes acknowledgment - -# Tier 2: Standard Production Alerts -Standard_Production: - Checks: All production services - Escalation: After 2 consecutive failures - Channels: - - Slack: #production-alerts channel - - Email: Engineering team distribution list - - PagerDuty: During business hours only - - Business_Hours: Extended hours (6 AM - 11 PM) - Response_SLA: 30 minutes acknowledgment - -# Tier 3: Non-Production Alerts -Non_Production: - Checks: Staging, development, internal tools - Escalation: After 3-5 consecutive failures - Channels: - - Slack: #dev-alerts channel - - Email: Development team - - Business_Hours: Business hours only - Response_SLA: Best effort - -# Tier 4: Security and Compliance -Security_Alerts: - Checks: SSL certificates, security scans - Escalation: Based on days remaining/severity - Channels: - - Email: Security team - - Slack: #security-alerts channel - - SIEM: Security information system - - Business_Hours: 24/7 for critical, business hours for warnings - Response_SLA: Varies by severity -``` - -### Team-Based Alert Distribution -Organize alerts by team responsibility: - -```yaml -# Backend Services Team -Backend_Team: - Services: ["*-api", "*-service", "database-*"] - Channels: - - Slack: #backend-alerts - - Email: backend-team@company.com - - PagerDuty: Backend on-call rotation - -# Frontend Team -Frontend_Team: - Services: ["web-app", "*-ui", "cdn-*"] - Channels: - - Slack: #frontend-alerts - - Email: frontend-team@company.com - - Browser: User journey monitoring alerts - -# Infrastructure Team -Infrastructure_Team: - Services: ["monitoring-*", "logging-*", "metrics-*"] - Channels: - - Slack: #infrastructure-alerts - - Email: devops-team@company.com - - PagerDuty: Infrastructure on-call - -# Security Team -Security_Team: - Services: ["*ssl*", "auth-*", "security-*"] - Channels: - - Slack: #security-alerts - - Email: security-team@company.com - - SIEM: Security incident and event management -``` - -## Alert Fatigue Prevention - -### Signal-to-Noise Optimization -Implement strategies to reduce alert fatigue: - - - -Monitor alert volume and response patterns for 2-4 weeks to establish baseline - - - -Track alerts that don't result in action and adjust thresholds or add retries - - - -Identify related alerts that should be grouped or have dependencies - - - -Gradually adjust escalation thresholds based on team response patterns - - - -Monthly review of alert effectiveness and team feedback - - - -### Alert Metrics and KPIs -Track alerting effectiveness with key metrics: - -```yaml -# Alert Quality Metrics -Alert_Quality_KPIs: - Signal_to_Noise_Ratio: >80% (alerts that result in action) - False_Positive_Rate: <20% (alerts with no action needed) - Mean_Time_to_Acknowledge: <5 minutes (critical), <30 minutes (standard) - Mean_Time_to_Resolution: Varies by severity - Alert_Volume_Trend: Decreasing over time (improving stability) - -# Team Response Metrics -Team_Response_KPIs: - Acknowledgment_Rate: >95% (alerts acknowledged) - Response_Time_Compliance: >90% within SLA - Escalation_Rate: <10% (alerts requiring escalation) - Alert_Fatigue_Score: Survey-based team feedback - -# System Health Metrics -System_Health_KPIs: - Check_Coverage: >90% of critical paths monitored - Alert_Coverage: >95% of customer-impacting issues detected - Recovery_Detection: >90% of recoveries properly notified - Maintenance_Window_Compliance: >95% (proper muting) -``` - -### Adaptive Alerting Patterns -Implement intelligent alerting that adapts to patterns: - -```yaml -# Time-Based Sensitivity -Adaptive_Sensitivity: - Business_Hours: Standard thresholds - After_Hours: Increased thresholds for non-critical alerts - Weekends: Reduced sensitivity for development systems - Holidays: Critical alerts only - -# Load-Based Alerting -Load_Adaptive_Thresholds: - High_Traffic_Periods: Increased response time tolerance - Low_Traffic_Periods: Decreased tolerance (expect better performance) - Deployment_Windows: Temporary threshold adjustments - Maintenance_Periods: Automatic muting with exceptions - -# Historical Pattern Recognition -Pattern_Based_Alerting: - Known_Flaky_Services: Higher retry counts and thresholds - Seasonal_Patterns: Adjust for known traffic variations - Deployment_Correlations: Link alerts to recent deployments - External_Dependencies: Account for third-party service patterns -``` - -## Environment-Specific Strategies - -### Production vs Non-Production Alerting -Tailor alerting approaches for different environments: - - - -**Maximum Reliability** -```yaml -Philosophy: "Fail fast, alert immediately" -Escalation: Aggressive (immediate for critical) -Channels: Full escalation chain -Retries: Minimal (quick detection) -Coverage: Comprehensive monitoring -Response: 24/7 on-call coverage -``` - - - -**Balanced Noise Reduction** -```yaml -Philosophy: "Reduce noise, focus on blockers" -Escalation: Conservative (multiple failures) -Channels: Team notifications only -Retries: Aggressive (reduce false positives) -Coverage: Core functionality only -Response: Business hours support -``` - - - -### Service Criticality Classification -Implement tiered service classification: - -```yaml -# Critical Services (P1) -Critical_Services: - Examples: ["payment-api", "user-auth", "checkout-flow"] - Customer_Impact: Direct revenue/user impact - Alert_Strategy: Immediate escalation - Response_Time: <5 minutes - Coverage: Comprehensive (API + Browser + Performance) - -# Important Services (P2) -Important_Services: - Examples: ["search-api", "recommendation-engine", "analytics"] - Customer_Impact: Degraded experience - Alert_Strategy: 2 failure escalation - Response_Time: <30 minutes - Coverage: Core functionality monitoring - -# Standard Services (P3) -Standard_Services: - Examples: ["admin-tools", "reporting", "batch-jobs"] - Customer_Impact: Internal operations - Alert_Strategy: 3-5 failure escalation - Response_Time: <2 hours - Coverage: Basic health monitoring - -# Development Services (P4) -Development_Services: - Examples: ["test-environments", "staging-apis"] - Customer_Impact: Development productivity - Alert_Strategy: Conservative escalation - Response_Time: Best effort - Coverage: Minimal monitoring -``` - -## SSL Certificate Management - -### Proactive SSL Monitoring -Implement comprehensive SSL certificate management: - -```yaml -# SSL Alert Timeline -SSL_Alert_Strategy: - 90_Days_Before: Initial warning to security team - 60_Days_Before: Planning reminder + calendar entry - 30_Days_Before: Procurement/renewal initiation - 14_Days_Before: Urgent renewal warning - 7_Days_Before: Critical escalation to management - 3_Days_Before: Emergency procedures activation - 1_Day_Before: All-hands alert + communication plan - -# SSL Monitoring Coverage -SSL_Coverage: - Primary_Domains: All customer-facing endpoints - Subdomain_Monitoring: Wildcard and specific subdomains - API_Endpoints: All authenticated API services - CDN_Certificates: Content delivery network certificates - Internal_Services: Critical internal HTTPS services - -# SSL Alert Channels -SSL_Alert_Routing: - Security_Team: All SSL-related alerts - Infrastructure_Team: Certificate deployment issues - Engineering_Leads: Business-critical certificate alerts - Management: Emergency escalation (3 days before expiry) -``` - -### SSL Alert Automation -Automate certificate renewal workflows: - -```json -{ - "ssl_automation_webhook": { - "url": "https://api.certificate-manager.com/webhook", - "headers": { - "Authorization": "Bearer {{CERT_MANAGER_TOKEN}}", - "Content-Type": "application/json" - }, - "body": { - "domain": "{{SSL_CHECK_DOMAIN}}", - "days_remaining": {{SSL_DAYS_REMAINING}}, - "action": "{{#lt SSL_DAYS_REMAINING 30}}initiate_renewal{{else}}{{#lt SSL_DAYS_REMAINING 7}}urgent_renewal{{else}}monitor{{/lt}}{{/lt}}", - "priority": "{{#lt SSL_DAYS_REMAINING 7}}critical{{else}}{{#lt SSL_DAYS_REMAINING 30}}high{{else}}normal{{/lt}}{{/lt}}", - "notification_channels": [ - "{{#lt SSL_DAYS_REMAINING 7}}pagerduty{{/lt}}", - "slack", - "email" - ] - } - } -} -``` - -## Incident Response Integration - -### Alert-to-Incident Workflow -Seamlessly connect alerting to incident management: - - - -Critical alerts automatically create incidents in your incident management system - - - -Related alerts are grouped into the same incident for better context - - - -Failed acknowledgments automatically escalate through on-call rotations - - - -Status page updates and customer communication triggered by alert patterns - - - -Alert data feeds into post-incident reviews and improvement processes - - - -### Incident Severity Mapping -Map alert characteristics to incident severity: - -```yaml -# Incident Severity Matrix -Incident_Severity_Mapping: - SEV1_Critical: - Triggers: - - Customer-facing service complete outage - - Security breach indicators - - Data loss scenarios - - Payment system failures - Response: Immediate page + incident commander - Communication: Customer notification within 15 minutes - - SEV2_High: - Triggers: - - Significant performance degradation - - Partial service outage - - Major feature unavailable - - High error rates - Response: Page during business hours, 30min after hours - Communication: Internal teams + status page update - - SEV3_Medium: - Triggers: - - Minor performance issues - - Non-critical feature problems - - Infrastructure warnings - - Approaching capacity limits - Response: Standard team notification - Communication: Internal teams only - - SEV4_Low: - Triggers: - - Successful recoveries - - Planned maintenance - - Performance improvements - - Informational alerts - Response: Log and monitor - Communication: Optional team updates -``` - -## Maintenance and Optimization - -### Regular Alert Hygiene -Maintain alerting effectiveness over time: - - - -Review alert volume, false positives, and response patterns - - - -Adjust escalation thresholds based on service behavior changes - - - -Assess overall alerting strategy effectiveness with team feedback - - - -Evaluate alerting architecture and integration improvements - - - -### Alert Configuration Lifecycle -Manage alert configurations as part of service lifecycle: - -```yaml -# Service Onboarding -Service_Onboarding_Checklist: - - [ ] Identify service criticality level - - [ ] Configure basic health monitoring - - [ ] Set up appropriate alert thresholds - - [ ] Define escalation channels - - [ ] Test alert delivery - - [ ] Document alert procedures - -# Service Updates -Service_Update_Process: - - [ ] Review alert configuration relevance - - [ ] Update thresholds for performance changes - - [ ] Modify channels for team changes - - [ ] Test configuration updates - - [ ] Update documentation - -# Service Decommissioning -Service_Decommission_Process: - - [ ] Disable alert escalation - - [ ] Maintain monitoring for cleanup period - - [ ] Archive alert configuration - - [ ] Update team documentation - - [ ] Remove from alert channels -``` - -### Performance and Cost Optimization -Balance comprehensive monitoring with operational efficiency: - -```yaml -# Cost-Effective Monitoring -Optimization_Strategies: - Check_Frequency: Match to business requirements, not maximum capability - Location_Coverage: Strategic global placement, not every location - Retry_Logic: Intelligent retries reduce check volume - Alert_Aggregation: Group related alerts to reduce channel usage - -# Performance Optimization -Performance_Strategies: - Alert_Channel_Efficiency: Use webhooks for complex routing - Batch_Processing: Aggregate notifications for high-volume alerts - Caching: Cache alert state to prevent duplicate processing - Rate_Limiting: Protect downstream systems from alert floods -``` - -## Team Training and Documentation - -### Alerting Runbooks -Create comprehensive alert response documentation: - -```yaml -# Alert Runbook Template -Alert_Runbook_Structure: - Alert_Description: What the alert means - Severity_Level: P1/P2/P3 classification - Initial_Response: First steps to take - Investigation_Steps: How to diagnose the issue - Escalation_Path: When and how to escalate - Resolution_Steps: Common fixes and procedures - Prevention: How to prevent recurrence - -# Example: Payment API Failure Runbook -Payment_API_Failure_Runbook: - Description: "Payment processing API is failing or unavailable" - Severity: P1 (Critical - Revenue Impact) - Initial_Response: - - Acknowledge alert within 5 minutes - - Check payment provider status pages - - Verify database connectivity - - Review recent deployments - Investigation: - - Check error rates in monitoring dashboard - - Review application logs for error patterns - - Verify third-party payment processor status - - Check network connectivity to payment services - Escalation: - - If no resolution in 15 minutes, escalate to engineering manager - - If payment processor issue, escalate to business team - - If database issue, escalate to DBA team -``` - -### Team Alert Training -Ensure team readiness for effective alert response: - - - -Regular training on alert acknowledgment, investigation, and escalation procedures - - - -Keep alert runbooks current with service changes and lessons learned - - - -Practice incident response with simulated alerts and scenarios - - - -Ensure team knows how to use monitoring tools, alert channels, and escalation systems - - - -Regular retrospectives on alert effectiveness and response procedures - - - - -Effective alerting is as much about people and processes as it is about technology. Focus on creating sustainable practices that improve over time rather than perfect configurations from day one. - - - -Alert fatigue is a serious risk to incident response effectiveness. Prioritize signal quality over alert quantity, and regularly review and tune your alerting to maintain team confidence in the system. - - - -Start with conservative alerting and gradually increase sensitivity as your team builds confidence and processes mature. It's better to miss a few edge cases initially than to overwhelm your team with false positives. - diff --git a/concepts/monitors.mdx b/concepts/monitors.mdx deleted file mode 100644 index 07ed5bbc..00000000 --- a/concepts/monitors.mdx +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: 'What are Monitors?' -description: 'Learn about Uptime Monitors at Checkly' -sidebarTitle: 'Monitors' -canonical: 'https://www.checklyhq.com/docs/concepts/monitors/' ---- - - -Monitors are Checkly's streamlined **Uptime offering** designed for straightforward, continuous monitoring of your essential services. Each Monitor represents a single, focused monitoring task that runs at a set interval you configure. Monitors are sold individually, making them perfect for teams that need simple, cost-effective uptime monitoring. - -Think of Monitors as your dedicated sentries—each one has a specific job and runs independently at its own schedule. They're designed for simplicity and reliability, focusing on the core question: "Is my service up and responding correctly?" - -## Types of Monitors - -Checkly offers three types of Monitors, each optimized for different monitoring scenarios: - - - - -Monitor HTTP/HTTPS endpoints for availability and basic performance. URL Monitors check if your websites and APIs are responding correctly by making HTTP requests and validating the response. - -**Perfect for:** -- Website uptime monitoring -- API endpoint availability -- Basic performance tracking -- SSL certificate monitoring - - - -Verify connectivity to any TCP service by establishing connections to specific hosts and ports. TCP Monitors test the availability of non-HTTP services and infrastructure components. - -**Perfect for:** -- Database connectivity -- Custom application services -- Network service availability -- Port accessibility testing - - - -Monitor scheduled processes, cron jobs, and batch operations that should "check in" at regular intervals. Instead of actively testing your service, Heartbeat Monitors wait to receive a signal from your system. - -**Perfect for:** -- Backup job verification -- Scheduled task monitoring -- Batch process oversight -- Data pipeline health - - - - -## How Monitors Work - -Each Monitor operates independently with its own configuration: - -- **Individual Scheduling**: Set each Monitor to run at intervals that make sense for that specific service (every 1 minute, 5 minutes, 30 minutes, etc.) -- **Simple Configuration**: Straightforward setup focused on the essentials—URL, expected response, timeout settings -- **Dedicated Alerting**: Each Monitor can have its own alert rules and notification channels -- **Pay-per-Monitor**: Pricing scales linearly with the number of Monitors you need - -## Monitors vs Checks - -Monitors are part of Checkly's **Uptime offering**—they're designed for teams who need reliable, no-frills monitoring with predictable costs. Each Monitor focuses on one specific task and runs independently. - -If you need more sophisticated testing capabilities like multi-step workflows, complex browser automation, or advanced scripting, you'll want to explore [Checks](/concepts/checks)—our flexible monitoring solution that includes Browser Checks, Multistep Checks, and advanced API testing. - -## When to Choose Monitors - -Monitors are ideal when you need: - -- **Simple uptime monitoring** for websites and APIs -- **Predictable costs** with per-monitor pricing -- **Independent scheduling** for different services -- **Straightforward setup** without complex scripting -- **Basic alerting** when services go down or perform poorly - -Monitors provide the reliability and simplicity that many teams need for essential uptime monitoring, while Checks offer the flexibility and advanced capabilities for comprehensive end-to-end testing scenarios. \ No newline at end of file diff --git a/detect/synthetic-monitoring/api-checks/best-practices.mdx b/detect/synthetic-monitoring/api-checks/best-practices.mdx deleted file mode 100644 index 08b6a9df..00000000 --- a/detect/synthetic-monitoring/api-checks/best-practices.mdx +++ /dev/null @@ -1,584 +0,0 @@ ---- -title: 'API Check Best Practices' -description: 'Proven strategies, optimization techniques, and reliability patterns for implementing effective API monitoring with Checkly.' -sidebarTitle: 'Best Practices' -canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/api-checks/best-practices/' ---- - -Effective API monitoring requires thoughtful design, proper configuration, and ongoing optimization. These best practices ensure reliable, efficient, and maintainable API checks that provide actionable insights. - -## API Check Design Principles - -### 1. Monitor Business-Critical Paths -Focus on APIs that directly impact user experience and business operations: - -```typescript -// High-priority API checks -Priority 1: User authentication, payment processing, core features -Priority 2: Data retrieval, search, user management -Priority 3: Analytics, reporting, background processes - -// Example: Critical payment API -{ - "name": "Payment Gateway - Process Transaction", - "frequency": "Every 1 minute", - "locations": ["us-east-1", "eu-west-1", "ap-southeast-1"], - "method": "POST", - "url": "https://api.payments.com/v1/transactions", - "thresholds": { - "degraded": 1000, - "failed": 3000 - } -} -``` - -### 2. Use Realistic Test Data -Ensure your API checks simulate real user scenarios: - -```typescript -// Good: Realistic test data -{ - "body": { - "email": "test.user@example.com", - "amount": 99.99, - "currency": "USD", - "payment_method": "card", - "metadata": { - "order_id": "ORD-12345", - "source": "web_checkout" - } - } -} - -// Avoid: Unrealistic or minimal data -{ - "body": { - "email": "test", - "amount": 1 - } -} -``` - -### 3. Implement Comprehensive Validation -Validate both successful responses and error conditions: - -```typescript -// Comprehensive assertion strategy -const assertions = [ - // Status validation - "expect(response.status).to.equal(200)", - - // Performance validation - "expect(response.responseTime).to.be.below(2000)", - - // Content structure validation - "const data = JSON.parse(response.body)", - "expect(data).to.have.property('id')", - "expect(data).to.have.property('status')", - - // Business logic validation - "expect(data.status).to.be.oneOf(['success', 'pending'])", - "expect(data.timestamp).to.be.a('string')", - - // Security validation - "expect(response.headers['content-type']).to.include('application/json')", - "expect(response.headers).to.not.have.property('x-debug-info')" -] -``` - -## Performance Optimization - -### 1. Set Appropriate Timeouts -Configure timeouts based on API characteristics and SLA requirements: - -```yaml -# Fast APIs (authentication, simple queries) -Request Timeout: 10 seconds -Degraded Threshold: 500ms -Failed Threshold: 2000ms - -# Standard APIs (data retrieval, processing) -Request Timeout: 30 seconds -Degraded Threshold: 1000ms -Failed Threshold: 5000ms - -# Complex APIs (reports, analytics, file processing) -Request Timeout: 60 seconds -Degraded Threshold: 5000ms -Failed Threshold: 15000ms -``` - -### 2. Optimize Check Frequency -Balance monitoring coverage with resource usage: - -```typescript -// Frequency guidelines by API criticality -const frequencyMatrix = { - critical: { - production: "Every 1 minute", - staging: "Every 5 minutes", - development: "Every 15 minutes" - }, - important: { - production: "Every 5 minutes", - staging: "Every 10 minutes", - development: "Every 30 minutes" - }, - standard: { - production: "Every 15 minutes", - staging: "Every 30 minutes", - development: "Every 60 minutes" - } -} -``` - -### 3. Minimize Response Processing -Efficient assertion writing for better performance: - -```typescript -// Efficient: Direct property access -"expect(JSON.parse(response.body).status).to.equal('active')" - -// Less efficient: Multiple parsing -"const data = JSON.parse(response.body)", -"const user = data.user", -"const profile = user.profile", -"expect(profile.status).to.equal('active')" - -// Optimized approach -"const data = JSON.parse(response.body)", -"expect(data.user?.profile?.status).to.equal('active')" -``` - -## Security and Authentication - -### 1. Secure Credential Management -Always use environment variables for sensitive data: - -```typescript -// Good: Environment variables -{ - "headers": { - "Authorization": "Bearer {{API_TOKEN}}", - "X-API-Key": "{{API_KEY}}", - "X-Client-ID": "{{CLIENT_ID}}" - } -} - -// Security checklist for credentials: -// ✓ Store in environment variables -// ✓ Use least-privilege API keys -// ✓ Rotate credentials regularly -// ✓ Monitor for credential exposure -// ✓ Use different keys per environment -``` - -### 2. Authentication Flow Monitoring -Monitor authentication mechanisms separately from business logic: - -```typescript -// Separate authentication check -{ - "name": "OAuth Token Generation", - "method": "POST", - "url": "https://api.example.com/oauth/token", - "body": { - "grant_type": "client_credentials", - "client_id": "{{CLIENT_ID}}", - "client_secret": "{{CLIENT_SECRET}}" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "const auth = JSON.parse(response.body)", - "expect(auth.access_token).to.be.a('string')", - "expect(auth.expires_in).to.be.above(3600)" - ] -} -``` - -### 3. Rate Limiting Awareness -Design checks that respect API rate limits: - -```typescript -// Rate limit monitoring -{ - "assertions": [ - "expect(response.status).to.not.equal(429)", // No rate limiting - "expect(response.headers['x-rate-limit-remaining']).to.exist", - "const remaining = parseInt(response.headers['x-rate-limit-remaining'])", - "expect(remaining).to.be.above(10)" // Ensure buffer - ] -} - -// Setup script to handle rate limits -const setupScript = ` -if (response.status === 429) { - const retryAfter = response.headers['retry-after'] || '60' - console.log('Rate limited, retry after: ' + retryAfter + ' seconds') - throw new Error('Rate limit exceeded') -} -` -``` - -## Error Handling and Reliability - -### 1. Robust Error Detection -Validate expected error responses and handle edge cases: - -```typescript -// Test error handling -{ - "name": "API Error Response Validation", - "method": "GET", - "url": "https://api.example.com/invalid-endpoint", - "assertions": [ - "expect(response.status).to.equal(404)", - "const error = JSON.parse(response.body)", - "expect(error.error).to.be.a('string')", - "expect(error.error_code).to.match(/^[A-Z_]+$/)", - "expect(error.message).to.be.a('string')", - "expect(error.request_id).to.match(/^req_[a-zA-Z0-9]+$/)" - ] -} -``` - -### 2. Graceful Degradation Testing -Monitor API behavior under various conditions: - -```typescript -// Network and performance edge cases -const edgeCaseChecks = [ - { - name: "API Response with Large Payload", - params: { limit: 1000 }, - maxResponseTime: 10000 - }, - { - name: "API Response with Invalid Parameters", - params: { invalid_param: "test" }, - expectedStatus: 400 - }, - { - name: "API Response with Missing Authentication", - headers: {}, // No auth headers - expectedStatus: 401 - } -] -``` - -### 3. Retry and Recovery Patterns -Configure appropriate retry strategies: - -```yaml -# Retry configuration by API type -Critical APIs: - Retry Strategy: Immediate retry once - Retry Delay: 5 seconds - Max Retries: 1 - -Standard APIs: - Retry Strategy: Exponential backoff - Initial Delay: 10 seconds - Max Retries: 2 - -Background APIs: - Retry Strategy: Linear backoff - Retry Delay: 30 seconds - Max Retries: 3 -``` - -## Data Validation Strategies - -### 1. Schema Validation -Validate response structure and data types: - -```typescript -// Comprehensive schema validation -const userResponseValidation = [ - // Type validation - "const user = JSON.parse(response.body)", - "expect(user.id).to.be.a('number')", - "expect(user.email).to.be.a('string')", - "expect(user.created_at).to.be.a('string')", - - // Format validation - "expect(user.email).to.match(/^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/)", - "expect(user.created_at).to.match(/^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}/)", - - // Business logic validation - "expect(user.status).to.be.oneOf(['active', 'pending', 'suspended'])", - "expect(user.role).to.be.oneOf(['user', 'admin', 'moderator'])", - - // Relationship validation - "if (user.profile) {", - " expect(user.profile.user_id).to.equal(user.id)", - "}" -] -``` - -### 2. Range and Boundary Validation -Test data boundaries and edge cases: - -```typescript -// Boundary testing assertions -const boundaryValidation = [ - // Numeric ranges - "expect(data.age).to.be.within(0, 120)", - "expect(data.price).to.be.above(0)", - "expect(data.discount).to.be.within(0, 100)", - - // String lengths - "expect(data.name.length).to.be.at.most(255)", - "expect(data.description.length).to.be.at.most(1000)", - - // Array sizes - "expect(data.items.length).to.be.at.most(100)", - "expect(data.tags.length).to.be.within(1, 10)", - - // Date ranges - "const createdDate = new Date(data.created_at)", - "const now = new Date()", - "expect(createdDate).to.be.below(now)" -] -``` - -### 3. Cross-Field Validation -Validate relationships between data fields: - -```typescript -// Relational data validation -const crossFieldValidation = [ - "const order = JSON.parse(response.body)", - - // Total calculation validation - "const expectedTotal = order.items.reduce((sum, item) => sum + (item.price * item.quantity), 0)", - "expect(order.total).to.be.closeTo(expectedTotal, 0.01)", - - // Status consistency - "if (order.status === 'completed') {", - " expect(order.payment_status).to.equal('paid')", - " expect(order.fulfillment_status).to.be.oneOf(['shipped', 'delivered'])", - "}", - - // Date logical ordering - "const created = new Date(order.created_at)", - "const updated = new Date(order.updated_at)", - "expect(updated).to.be.at.least(created)" -] -``` - -## Monitoring Strategy Optimization - -### 1. Geographic Distribution -Optimize monitoring locations based on user distribution: - -```typescript -// Location strategy by user base -const locationStrategy = { - global: ["us-east-1", "eu-west-1", "ap-southeast-1", "ap-northeast-1"], - americas: ["us-east-1", "us-west-2", "ca-central-1", "sa-east-1"], - europe: ["eu-west-1", "eu-central-1", "eu-north-1"], - asia: ["ap-southeast-1", "ap-northeast-1", "ap-south-1"], - oceania: ["ap-southeast-2"] -} - -// Performance expectations by region -const regionalThresholds = { - primary: { degraded: 500, failed: 2000 }, - secondary: { degraded: 1000, failed: 3000 }, - distant: { degraded: 2000, failed: 5000 } -} -``` - -### 2. Alert Optimization -Configure intelligent alerting to reduce noise: - -```yaml -# Alert escalation strategy -Immediate Alerts: - - API completely down (5xx errors) - - Authentication failures - - Payment processing failures - - Security-related errors - -Warning Alerts: - - Performance degradation (> 2x baseline) - - Increased error rates (> 5%) - - Rate limiting encountered - -Informational: - - Successful recovery after failure - - Performance improvements - - Configuration changes -``` - -### 3. Maintenance Windows -Handle planned maintenance and deployments: - -```typescript -// Maintenance window configuration -const maintenanceConfig = { - schedule: { - weekly: "Sunday 02:00-04:00 UTC", - monthly: "First Sunday 00:00-06:00 UTC" - }, - alerting: { - disable: true, - notification: "Maintenance window active" - }, - monitoring: { - continue: true, - reduced_frequency: true - } -} -``` - -## Advanced Configuration Patterns - -### 1. Dynamic Test Data -Generate unique test data to avoid conflicts: - -```javascript -// Setup script for dynamic data -const generateTestData = () => { - const timestamp = Date.now() - const randomId = Math.random().toString(36).substr(2, 9) - - process.env.TEST_EMAIL = `test-${timestamp}@example.com` - process.env.TEST_ORDER_ID = `ORD-${timestamp}-${randomId}` - process.env.TEST_CUSTOMER_ID = `CUST-${randomId}` -} - -generateTestData() -``` - -### 2. Conditional Logic -Implement smart checks that adapt to API responses: - -```javascript -// Conditional assertion based on response data -const conditionalAssertions = ` -const data = JSON.parse(response.body) - -if (data.type === 'premium_user') { - expect(data.features).to.include('advanced_analytics') - expect(data.limits.api_calls).to.be.above(10000) -} else if (data.type === 'basic_user') { - expect(data.limits.api_calls).to.be.below(1000) -} - -if (data.subscription && data.subscription.status === 'active') { - expect(data.access_level).to.be.oneOf(['standard', 'premium']) -} else { - expect(data.access_level).to.equal('limited') -} -` -``` - -### 3. Multi-Environment Testing -Coordinate testing across different environments: - -```typescript -// Environment-specific configuration -const environmentConfig = { - development: { - baseUrl: "https://api-dev.example.com", - frequency: "Every 30 minutes", - alerting: false, - timeout: 60000 - }, - staging: { - baseUrl: "https://api-staging.example.com", - frequency: "Every 10 minutes", - alerting: "team-only", - timeout: 30000 - }, - production: { - baseUrl: "https://api.example.com", - frequency: "Every 2 minutes", - alerting: "full", - timeout: 15000 - } -} -``` - -## Maintenance and Optimization - -### 1. Regular Review Process -Establish processes for ongoing optimization: - -```yaml -Weekly Review: - - Check failure rates and response times - - Review alert noise and false positives - - Validate test data currency - - Update environment variables - -Monthly Review: - - Analyze performance trends - - Review and update thresholds - - Assess coverage gaps - - Update documentation - -Quarterly Review: - - Strategic monitoring alignment - - Technology stack updates - - Security credential rotation - - Monitoring cost optimization -``` - -### 2. Performance Baseline Management -Track and update performance expectations: - -```typescript -// Baseline tracking approach -const performanceBaselines = { - updateFrequency: "weekly", - calculation: "95th percentile over 7 days", - thresholds: { - degraded: "baseline * 2", - failed: "baseline * 5" - }, - triggers: { - recalculate: "significant_change > 20%", - alert: "degradation > 48_hours" - } -} -``` - -### 3. Documentation and Knowledge Sharing -Maintain comprehensive monitoring documentation: - -```markdown -# API Check Documentation Template - -## Check Purpose -- Business criticality: [High/Medium/Low] -- User impact: [Description] -- Dependencies: [List of dependencies] - -## Technical Details -- Endpoint: [URL] -- Method: [HTTP method] -- Authentication: [Type and requirements] -- Expected response: [Format and content] - -## Monitoring Configuration -- Frequency: [Schedule] -- Locations: [Geographic distribution] -- Thresholds: [Performance expectations] -- Alerting: [Notification strategy] - -## Troubleshooting -- Common failures: [Known issues and solutions] -- Escalation path: [Contact information] -- Related documentation: [Links to relevant docs] -``` - - -Effective API monitoring is an iterative process. Start with basic checks and gradually add sophistication based on your specific needs and operational experience. - - - -Use Checkly's CLI to manage API checks as code, enabling version control, peer review, and automated deployment of monitoring configurations. - \ No newline at end of file diff --git a/detect/synthetic-monitoring/api-checks/examples.mdx b/detect/synthetic-monitoring/api-checks/examples.mdx deleted file mode 100644 index dd4aaee8..00000000 --- a/detect/synthetic-monitoring/api-checks/examples.mdx +++ /dev/null @@ -1,567 +0,0 @@ ---- -title: 'API Check Examples' -description: 'Real-world examples and implementation patterns for monitoring APIs with Checkly API checks across different industries and scenarios.' -sidebarTitle: 'Examples' -canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/api-checks/examples/' ---- - -API checks excel at validating backend services, microservices, and third-party integrations. These real-world use cases demonstrate how to implement comprehensive API monitoring across different industries and scenarios. - -## E-commerce and Retail - -### Product Catalog APIs -Monitor product data retrieval and search functionality: - -```typescript -// Product search API validation -{ - "method": "GET", - "url": "https://api.shop.com/v1/products/search?q=laptop&limit=10", - "headers": { - "Authorization": "Bearer {{API_TOKEN}}", - "Accept": "application/json" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "const data = JSON.parse(response.body)", - "expect(data.products).to.be.an('array')", - "expect(data.products.length).to.be.at.most(10)", - "expect(data.products[0]).to.have.property('id')", - "expect(data.products[0]).to.have.property('name')", - "expect(data.products[0]).to.have.property('price')", - "expect(data.total_count).to.be.a('number')" - ] -} -``` - -### Inventory Management -Validate stock levels and inventory updates: - -```typescript -// Inventory check API -{ - "method": "GET", - "url": "https://api.shop.com/v1/inventory/{{PRODUCT_ID}}", - "headers": { - "Authorization": "Bearer {{INVENTORY_TOKEN}}", - "Content-Type": "application/json" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "const inventory = JSON.parse(response.body)", - "expect(inventory.product_id).to.equal('{{PRODUCT_ID}}')", - "expect(inventory.available_quantity).to.be.a('number')", - "expect(inventory.available_quantity).to.be.at.least(0)", - "expect(inventory.reserved_quantity).to.be.a('number')", - "expect(inventory.last_updated).to.match(/\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}/)" - ] -} -``` - -### Payment Gateway Integration -Monitor payment processing and transaction APIs: - -```typescript -// Payment gateway health check -{ - "method": "POST", - "url": "https://api.payments.com/v1/transactions/validate", - "headers": { - "Authorization": "Bearer {{PAYMENT_API_KEY}}", - "Content-Type": "application/json" - }, - "body": { - "amount": 100, - "currency": "USD", - "payment_method": "test_card", - "test_mode": true - }, - "assertions": [ - "expect(response.status).to.be.oneOf([200, 201])", - "const transaction = JSON.parse(response.body)", - "expect(transaction.status).to.be.oneOf(['authorized', 'succeeded'])", - "expect(transaction.amount).to.equal(100)", - "expect(transaction.currency).to.equal('USD')", - "expect(transaction.transaction_id).to.match(/^txn_/)" - ] -} -``` - -## SaaS and Software Platforms - -### User Authentication APIs -Validate authentication and authorization flows: - -```typescript -// OAuth token validation -{ - "method": "POST", - "url": "https://api.saas.com/v1/auth/token", - "headers": { - "Content-Type": "application/x-www-form-urlencoded" - }, - "body": "grant_type=client_credentials&client_id={{CLIENT_ID}}&client_secret={{CLIENT_SECRET}}", - "assertions": [ - "expect(response.status).to.equal(200)", - "const auth = JSON.parse(response.body)", - "expect(auth.access_token).to.be.a('string')", - "expect(auth.token_type).to.equal('Bearer')", - "expect(auth.expires_in).to.be.a('number')", - "expect(auth.expires_in).to.be.above(3600)", // At least 1 hour - "expect(auth.scope).to.include('read')" - ] -} -``` - -### User Management APIs -Monitor user profile and account management: - -```typescript -// User profile retrieval -{ - "method": "GET", - "url": "https://api.saas.com/v1/users/{{USER_ID}}", - "headers": { - "Authorization": "Bearer {{ACCESS_TOKEN}}", - "Accept": "application/json" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "const user = JSON.parse(response.body)", - "expect(user.id).to.equal('{{USER_ID}}')", - "expect(user.email).to.match(/^[^\\s@]+@[^\\s@]+\\.[^\\s@]+$/)", - "expect(user.status).to.be.oneOf(['active', 'pending', 'suspended'])", - "expect(user.created_at).to.be.a('string')", - "expect(user.last_login).to.be.a('string')" - ] -} -``` - -### Subscription and Billing APIs -Validate subscription status and billing operations: - -```typescript -// Subscription status check -{ - "method": "GET", - "url": "https://api.saas.com/v1/subscriptions/{{SUBSCRIPTION_ID}}", - "headers": { - "Authorization": "Bearer {{API_TOKEN}}", - "Accept": "application/json" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "const subscription = JSON.parse(response.body)", - "expect(subscription.id).to.equal('{{SUBSCRIPTION_ID}}')", - "expect(subscription.status).to.be.oneOf(['active', 'trial', 'past_due', 'canceled'])", - "expect(subscription.plan).to.have.property('id')", - "expect(subscription.current_period_end).to.be.a('string')", - "expect(new Date(subscription.current_period_end)).to.be.above(new Date())" - ] -} -``` - -## Financial Services - -### Account Balance APIs -Monitor account information and balance retrieval: - -```typescript -// Account balance check -{ - "method": "GET", - "url": "https://api.bank.com/v1/accounts/{{ACCOUNT_ID}}/balance", - "headers": { - "Authorization": "Bearer {{BANKING_TOKEN}}", - "X-Client-ID": "{{CLIENT_ID}}", - "Accept": "application/json" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "const balance = JSON.parse(response.body)", - "expect(balance.account_id).to.equal('{{ACCOUNT_ID}}')", - "expect(balance.available_balance).to.be.a('number')", - "expect(balance.current_balance).to.be.a('number')", - "expect(balance.currency).to.match(/^[A-Z]{3}$/)", - "expect(balance.last_updated).to.be.a('string')" - ] -} -``` - -### Transaction Processing -Validate transaction creation and processing: - -```typescript -// Transaction validation -{ - "method": "POST", - "url": "https://api.bank.com/v1/transactions", - "headers": { - "Authorization": "Bearer {{BANKING_TOKEN}}", - "Content-Type": "application/json" - }, - "body": { - "from_account": "{{FROM_ACCOUNT}}", - "to_account": "{{TO_ACCOUNT}}", - "amount": 50.00, - "currency": "USD", - "description": "API Test Transfer", - "test_mode": true - }, - "assertions": [ - "expect(response.status).to.be.oneOf([200, 201, 202])", - "const transaction = JSON.parse(response.body)", - "expect(transaction.id).to.be.a('string')", - "expect(transaction.status).to.be.oneOf(['pending', 'processing', 'completed'])", - "expect(transaction.amount).to.equal(50.00)", - "expect(transaction.currency).to.equal('USD')" - ] -} -``` - -### Compliance and Risk APIs -Monitor regulatory compliance and risk assessment: - -```typescript -// AML/KYC validation -{ - "method": "POST", - "url": "https://api.compliance.com/v1/kyc/validate", - "headers": { - "Authorization": "Bearer {{COMPLIANCE_TOKEN}}", - "Content-Type": "application/json" - }, - "body": { - "customer_id": "{{CUSTOMER_ID}}", - "document_type": "passport", - "document_number": "TEST123456" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "const validation = JSON.parse(response.body)", - "expect(validation.status).to.be.oneOf(['verified', 'pending', 'rejected'])", - "expect(validation.confidence_score).to.be.a('number')", - "expect(validation.confidence_score).to.be.within(0, 100)", - "expect(validation.risk_level).to.be.oneOf(['low', 'medium', 'high'])" - ] -} -``` - -## Healthcare and Life Sciences - -### Patient Management APIs -Monitor patient data access and management: - -```typescript -// Patient record retrieval (FHIR compliant) -{ - "method": "GET", - "url": "https://api.healthcare.com/fhir/Patient/{{PATIENT_ID}}", - "headers": { - "Authorization": "Bearer {{HEALTHCARE_TOKEN}}", - "Accept": "application/fhir+json" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "const patient = JSON.parse(response.body)", - "expect(patient.resourceType).to.equal('Patient')", - "expect(patient.id).to.equal('{{PATIENT_ID}}')", - "expect(patient.identifier).to.be.an('array')", - "expect(patient.name).to.be.an('array')", - "expect(patient.active).to.be.a('boolean')" - ] -} -``` - -### Appointment Scheduling -Validate appointment booking and management: - -```typescript -// Appointment availability check -{ - "method": "GET", - "url": "https://api.healthcare.com/v1/appointments/availability", - "headers": { - "Authorization": "Bearer {{HEALTHCARE_TOKEN}}", - "Accept": "application/json" - }, - "params": { - "provider_id": "{{PROVIDER_ID}}", - "date": "2024-03-15", - "service_type": "consultation" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "const availability = JSON.parse(response.body)", - "expect(availability.date).to.equal('2024-03-15')", - "expect(availability.slots).to.be.an('array')", - "availability.slots.forEach(slot => {", - " expect(slot.start_time).to.match(/^\\d{2}:\\d{2}$/)", - " expect(slot.available).to.be.a('boolean')", - "})" - ] -} -``` - -## IoT and Smart Devices - -### Device Status Monitoring -Monitor IoT device connectivity and status: - -```typescript -// IoT device status check -{ - "method": "GET", - "url": "https://api.iot.com/v1/devices/{{DEVICE_ID}}/status", - "headers": { - "Authorization": "Bearer {{IOT_TOKEN}}", - "Accept": "application/json" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "const device = JSON.parse(response.body)", - "expect(device.device_id).to.equal('{{DEVICE_ID}}')", - "expect(device.status).to.be.oneOf(['online', 'offline', 'maintenance'])", - "expect(device.last_seen).to.be.a('string')", - "expect(device.battery_level).to.be.within(0, 100)", - "expect(device.firmware_version).to.match(/^\\d+\\.\\d+\\.\\d+$/)" - ] -} -``` - -### Sensor Data APIs -Validate sensor data collection and processing: - -```typescript -// Sensor data retrieval -{ - "method": "GET", - "url": "https://api.iot.com/v1/sensors/{{SENSOR_ID}}/data", - "headers": { - "Authorization": "Bearer {{IOT_TOKEN}}", - "Accept": "application/json" - }, - "params": { - "start_time": "2024-03-15T00:00:00Z", - "end_time": "2024-03-15T23:59:59Z" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "const data = JSON.parse(response.body)", - "expect(data.sensor_id).to.equal('{{SENSOR_ID}}')", - "expect(data.readings).to.be.an('array')", - "data.readings.forEach(reading => {", - " expect(reading.timestamp).to.be.a('string')", - " expect(reading.value).to.be.a('number')", - " expect(reading.unit).to.be.a('string')", - "})" - ] -} -``` - -## Media and Content Management - -### Content Delivery APIs -Monitor content serving and CDN performance: - -```typescript -// Content metadata API -{ - "method": "GET", - "url": "https://api.media.com/v1/content/{{CONTENT_ID}}", - "headers": { - "Authorization": "Bearer {{MEDIA_TOKEN}}", - "Accept": "application/json" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "const content = JSON.parse(response.body)", - "expect(content.id).to.equal('{{CONTENT_ID}}')", - "expect(content.type).to.be.oneOf(['video', 'audio', 'image', 'document'])", - "expect(content.url).to.match(/^https?:\\/\\//)", - "expect(content.file_size).to.be.a('number')", - "expect(content.duration).to.be.a('number')", - "expect(content.status).to.equal('published')" - ] -} -``` - -### Video Streaming APIs -Validate video processing and streaming: - -```typescript -// Video stream health check -{ - "method": "GET", - "url": "https://api.streaming.com/v1/streams/{{STREAM_ID}}/health", - "headers": { - "Authorization": "Bearer {{STREAMING_TOKEN}}", - "Accept": "application/json" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "const stream = JSON.parse(response.body)", - "expect(stream.stream_id).to.equal('{{STREAM_ID}}')", - "expect(stream.status).to.be.oneOf(['live', 'idle', 'error'])", - "expect(stream.bitrate).to.be.a('number')", - "expect(stream.viewers).to.be.a('number')", - "expect(stream.quality).to.be.oneOf(['720p', '1080p', '4K'])" - ] -} -``` - -## API Monitoring Best Practices by Use Case - -### High-Frequency Monitoring -```yaml -# Critical business APIs -Frequency: Every 1-2 minutes -Locations: Primary user regions -Thresholds: - - Response time: < 500ms (degraded), < 2000ms (failed) - - Status codes: 2xx expected - - Availability: > 99.9% - -Use Cases: - - Payment processing - - User authentication - - Core business transactions -``` - -### Standard Business APIs -```yaml -# Important but non-critical APIs -Frequency: Every 5-10 minutes -Locations: Global coverage -Thresholds: - - Response time: < 1000ms (degraded), < 5000ms (failed) - - Status codes: 2xx expected - - Availability: > 99.5% - -Use Cases: - - Product catalogs - - User profiles - - Content management -``` - -### Background and Batch APIs -```yaml -# Batch processing and background services -Frequency: Every 15-30 minutes -Locations: Primary regions -Thresholds: - - Response time: < 3000ms (degraded), < 10000ms (failed) - - Status codes: 2xx or 202 expected - - Availability: > 99% - -Use Cases: - - Data processing - - Report generation - - Backup operations -``` - -## Advanced API Monitoring Patterns - -### Health Check Endpoints -Create comprehensive health checks that validate multiple components: - -```typescript -// Multi-component health check -{ - "method": "GET", - "url": "https://api.example.com/health", - "assertions": [ - "expect(response.status).to.equal(200)", - "const health = JSON.parse(response.body)", - "expect(health.status).to.equal('healthy')", - "expect(health.database).to.equal('connected')", - "expect(health.redis).to.equal('connected')", - "expect(health.external_apis).to.be.an('object')", - "Object.values(health.external_apis).forEach(status => {", - " expect(status).to.be.oneOf(['healthy', 'degraded'])", - "})" - ] -} -``` - -### Rate Limiting Validation -Monitor API rate limiting and quota management: - -```typescript -// Rate limit monitoring -{ - "method": "GET", - "url": "https://api.example.com/v1/data", - "headers": { - "Authorization": "Bearer {{API_TOKEN}}" - }, - "assertions": [ - "expect(response.status).to.equal(200)", - "expect(response.headers['x-rate-limit-limit']).to.exist", - "expect(response.headers['x-rate-limit-remaining']).to.exist", - "const remaining = parseInt(response.headers['x-rate-limit-remaining'])", - "expect(remaining).to.be.above(10)" // Ensure sufficient quota - ] -} -``` - -### Error Response Validation -Validate that error responses are properly formatted: - -```typescript -// Error handling validation -{ - "method": "GET", - "url": "https://api.example.com/v1/invalid-endpoint", - "assertions": [ - "expect(response.status).to.equal(404)", - "const error = JSON.parse(response.body)", - "expect(error.error).to.be.a('string')", - "expect(error.error_code).to.be.a('string')", - "expect(error.message).to.include('not found')", - "expect(error.request_id).to.be.a('string')" - ] -} -``` - -## Integration with Development Workflow - -### Environment-Specific Monitoring -```typescript -// Development environment -Base URL: https://api-dev.example.com -Frequency: Every 15 minutes -Alerts: Development team only - -// Staging environment -Base URL: https://api-staging.example.com -Frequency: Every 5 minutes -Alerts: QA team and development leads - -// Production environment -Base URL: https://api.example.com -Frequency: Every 1 minute -Alerts: On-call engineer, operations team -``` - -### CI/CD Integration -Monitor API deployments and validate releases: - -```typescript -// Post-deployment validation -{ - "method": "GET", - "url": "https://api.example.com/version", - "assertions": [ - "expect(response.status).to.equal(200)", - "const version = JSON.parse(response.body)", - "expect(version.build_number).to.equal('{{EXPECTED_BUILD}}')", - "expect(version.environment).to.equal('production')", - "expect(version.healthy).to.be.true" - ] -} -``` - - -API checks provide the foundation for comprehensive application monitoring. Combine multiple API checks with browser and multistep checks for complete coverage of your application ecosystem. - \ No newline at end of file diff --git a/detect/synthetic-monitoring/api-checks/setup-and-teardown.mdx b/detect/synthetic-monitoring/api-checks/setup-and-teardown.mdx index 7f7c45ff..8de2b245 100644 --- a/detect/synthetic-monitoring/api-checks/setup-and-teardown.mdx +++ b/detect/synthetic-monitoring/api-checks/setup-and-teardown.mdx @@ -142,7 +142,7 @@ Benefits of this structure: - Reuse authentication logic across multiple API checks - Test authentication logic separately from Checkly-specific code -Check our [setup script examples](/detect/synthetic-monitoring/api-checks/examples) for OAuth2, HMAC signing, JWT tokens, and other auth methods. +For more setup and teardown patterns, see the [setup scripts guide](/guides/setup-scripts-for-apis). ### Error handling in setup scripts @@ -341,4 +341,4 @@ Access environment variables in the request body with `{{MY_VALUE}}` notation. ![Checkly API check editor showing a JSON request body that uses the MY_VALUE environment variable.](/images/docs/images/api-checks/setup-env-variables.png) -For more examples, check our [setup script examples](/detect/synthetic-monitoring/api-checks/examples). +For more examples, see the [setup scripts guide](/guides/setup-scripts-for-apis). diff --git a/detect/synthetic-monitoring/browser-checks/best-practices.mdx b/detect/synthetic-monitoring/browser-checks/best-practices.mdx deleted file mode 100644 index 10d26380..00000000 --- a/detect/synthetic-monitoring/browser-checks/best-practices.mdx +++ /dev/null @@ -1,788 +0,0 @@ ---- -title: 'Browser Check Best Practices' -description: 'Proven strategies, optimization techniques, and reliability patterns for implementing effective browser automation monitoring with Checkly.' -sidebarTitle: 'Best Practices' -canonical: 'https://www.checklyhq.com/docs/detect/synthetic-monitoring/browser-checks/best-practices/' ---- - -Effective browser monitoring requires thoughtful test design, reliable selectors, and robust error handling. These best practices ensure your browser checks are maintainable, reliable, and provide actionable insights about user experience. - -## Test Design Principles - -### 1. Focus on Critical User Journeys -Prioritize the most important user workflows that directly impact business value: - -```typescript -// High-priority user journeys -const criticalJourneys = { - tier1: [ - 'User login/authentication', - 'Purchase/checkout flow', - 'Account registration', - 'Password reset' - ], - tier2: [ - 'Search and filtering', - 'Profile management', - 'Settings configuration', - 'Content creation' - ], - tier3: [ - 'Help and support access', - 'Advanced feature usage', - 'Integration setup', - 'Report generation' - ] -} - -// Example: Critical login workflow -test('User authentication flow - Critical Path', async ({ page }) => { - await page.goto('https://app.example.com/login') - - // Use realistic credentials - await page.fill('[data-testid="email"]', process.env.TEST_USER_EMAIL) - await page.fill('[data-testid="password"]', process.env.TEST_USER_PASSWORD) - await page.click('[data-testid="login-button"]') - - // Verify successful authentication - await expect(page.locator('[data-testid="user-dashboard"]')).toBeVisible() - await expect(page.locator('[data-testid="user-menu"]')).toContainText('Welcome') -}) -``` - -### 2. Design for Realistic User Behavior -Simulate actual user interactions and decision patterns: - -```typescript -// Good: Realistic user behavior -test('E-commerce product discovery', async ({ page }) => { - await page.goto('https://shop.example.com') - - // User browses categories first - await page.hover('[data-testid="electronics-category"]') - await page.click('[data-testid="laptops-subcategory"]') - - // Applies filters gradually - await page.selectOption('[data-testid="brand-filter"]', 'apple') - await page.waitForSelector('[data-testid="filtered-results"]') - - // Sorts by preference - await page.selectOption('[data-testid="sort-by"]', 'price-low-high') - await page.waitForSelector('[data-testid="sorted-results"]') - - // Views product details - await page.click('[data-testid="product-card"]:first-child') - await expect(page.locator('[data-testid="product-details"]')).toBeVisible() - - // Reads reviews before deciding - await page.click('[data-testid="reviews-tab"]') - await expect(page.locator('[data-testid="customer-reviews"]')).toBeVisible() -}) - -// Avoid: Unrealistic direct navigation -test('Direct product purchase - Not realistic', async ({ page }) => { - // Users rarely go directly to a specific product URL - await page.goto('https://shop.example.com/products/laptop-123') - await page.click('[data-testid="buy-now"]') -}) -``` - -### 3. Use Representative Test Data -Ensure test data reflects real user scenarios: - -```typescript -// Dynamic test data generation -const generateTestUser = () => { - const timestamp = Date.now() - const randomId = Math.random().toString(36).substr(2, 9) - - return { - email: `test-${timestamp}@example.com`, - firstName: 'Test', - lastName: 'User', - company: 'Test Company', - phone: '+1-555-0123', - address: { - street: '123 Test Street', - city: 'Boston', - state: 'MA', - zipCode: '02101' - } - } -} - -test('User registration with realistic data', async ({ page }) => { - const testUser = generateTestUser() - - await page.goto('https://app.example.com/register') - await page.fill('[name="firstName"]', testUser.firstName) - await page.fill('[name="lastName"]', testUser.lastName) - await page.fill('[name="email"]', testUser.email) - await page.fill('[name="company"]', testUser.company) - - // Use realistic password patterns - await page.fill('[name="password"]', 'SecureTest123!') - await page.fill('[name="confirmPassword"]', 'SecureTest123!') - - await page.click('[type="submit"]') -}) -``` - -## Selector Strategy and Element Interaction - -### 1. Implement a Selector Hierarchy -Use stable, maintainable selectors in order of preference: - -```typescript -// Selector preference hierarchy -const selectorStrategy = { - // 1. Test IDs (most stable) - testId: '[data-testid="submit-button"]', - - // 2. Text content (semantic and readable) - text: 'text=Submit Order', - - // 3. Role-based selectors (accessible) - role: 'role=button[name="Submit"]', - - // 4. Specific CSS selectors - css: 'button.submit-btn[type="submit"]', - - // 5. XPath (last resort) - xpath: '//button[@class="submit-btn" and @type="submit"]' -} - -// Good selector practices -test('Login with stable selectors', async ({ page }) => { - await page.goto('https://app.example.com/login') - - // Preferred: Test IDs - await page.fill('[data-testid="email-input"]', 'user@example.com') - await page.fill('[data-testid="password-input"]', 'password123') - await page.click('[data-testid="login-button"]') - - // Alternative: Text content - await page.click('text=Sign In') - - // Alternative: Role-based - await page.click('role=button[name="Login"]') -}) - -// Avoid: Brittle selectors -test('Fragile selectors to avoid', async ({ page }) => { - // Avoid: Position-dependent selectors - await page.click('button:nth-child(3)') - - // Avoid: Generic class names - await page.click('.btn') - - // Avoid: Complex hierarchical selectors - await page.click('div > div > div > button') - - // Avoid: Absolute XPath - await page.click('/html/body/div[1]/div[2]/form/button') -}) -``` - -### 2. Implement Robust Wait Strategies -Use appropriate waiting mechanisms for different scenarios: - -```typescript -// Comprehensive wait strategies -test('Robust waiting patterns', async ({ page }) => { - await page.goto('https://app.example.com') - - // Wait for specific elements - await page.waitForSelector('[data-testid="page-loaded"]') - - // Wait for network state - await page.waitForLoadState('networkidle') - - // Wait for URL changes - await page.click('[data-testid="navigate-dashboard"]') - await page.waitForURL('**/dashboard') - - // Wait for element state changes - await page.waitForSelector('[data-testid="submit-button"]:not([disabled])') - - // Wait for custom conditions - await page.waitForFunction(() => window.dataLoaded === true) - - // Wait for API responses - await page.waitForResponse(response => - response.url().includes('/api/user') && response.status() === 200 - ) - - // Conditional waiting with timeouts - try { - await page.waitForSelector('[data-testid="optional-modal"]', { timeout: 5000 }) - await page.click('[data-testid="modal-close"]') - } catch (error) { - // Continue if modal doesn't appear - console.log('Optional modal not present') - } -}) -``` - -### 3. Handle Dynamic Content Effectively -Deal with dynamic and asynchronous content: - -```typescript -// Dynamic content handling -test('Handle dynamic and async content', async ({ page }) => { - await page.goto('https://app.example.com/dashboard') - - // Wait for data loading - await page.waitForSelector('[data-testid="loading-spinner"]', { state: 'hidden' }) - - // Handle infinite scroll - const loadMoreContent = async () => { - let previousCount = 0 - let currentCount = await page.locator('[data-testid="content-item"]').count() - - while (currentCount > previousCount) { - previousCount = currentCount - await page.evaluate(() => window.scrollTo(0, document.body.scrollHeight)) - await page.waitForTimeout(1000) // Allow content to load - currentCount = await page.locator('[data-testid="content-item"]').count() - } - } - - await loadMoreContent() - - // Handle real-time updates - const initialCount = await page.locator('[data-testid="notification"]').count() - - // Trigger action that generates notifications - await page.click('[data-testid="send-message"]') - - // Wait for new notification - await page.waitForFunction( - (expectedCount) => document.querySelectorAll('[data-testid="notification"]').length > expectedCount, - initialCount - ) - - // Handle form field dependencies - await page.selectOption('[data-testid="country-select"]', 'US') - await page.waitForSelector('[data-testid="state-select"]:not([disabled])') - await page.selectOption('[data-testid="state-select"]', 'CA') -}) -``` - -## Performance and Reliability Optimization - -### 1. Optimize Test Execution Speed -Implement techniques to improve test performance: - -```typescript -// Performance optimization techniques -test('Optimized test execution', async ({ page }) => { - // Block unnecessary resources - await page.route('**/*.{png,jpg,jpeg,gif,svg,woff,woff2}', route => route.abort()) - await page.route('**/analytics/**', route => route.abort()) - await page.route('**/tracking/**', route => route.abort()) - - // Parallel navigation and actions - await Promise.all([ - page.goto('https://app.example.com'), - page.waitForSelector('[data-testid="main-content"]') - ]) - - // Batch similar operations - await Promise.all([ - page.fill('[data-testid="first-name"]', 'John'), - page.fill('[data-testid="last-name"]', 'Doe'), - page.fill('[data-testid="email"]', 'john@example.com') - ]) - - // Use efficient selectors - const fastLocator = page.locator('[data-testid="specific-element"]') - const slowLocator = page.locator('div').filter({ hasText: 'Some text' }).locator('button') - - // Prefer direct element interactions - await fastLocator.click() -}) - -// Resource management -test.beforeEach(async ({ page }) => { - // Configure performance settings - await page.setExtraHTTPHeaders({ - 'User-Agent': 'Checkly-Monitor/1.0' - }) - - // Set reasonable timeouts - page.setDefaultTimeout(30000) - page.setDefaultNavigationTimeout(30000) -}) -``` - -### 2. Implement Error Recovery Patterns -Design tests that gracefully handle failures: - -```typescript -// Error recovery and resilience -test('Resilient test patterns', async ({ page }) => { - const maxRetries = 3 - let attempt = 0 - - // Retry wrapper for flaky operations - const retryOperation = async (operation, description) => { - for (attempt = 1; attempt <= maxRetries; attempt++) { - try { - await operation() - console.log(`${description} succeeded on attempt ${attempt}`) - return - } catch (error) { - console.log(`${description} failed on attempt ${attempt}: ${error.message}`) - if (attempt === maxRetries) throw error - await page.waitForTimeout(1000 * attempt) // Exponential backoff - } - } - } - - // Handle intermittent network issues - await retryOperation(async () => { - await page.goto('https://app.example.com', { waitUntil: 'networkidle' }) - }, 'Page navigation') - - // Graceful degradation for optional features - try { - await page.click('[data-testid="promotional-banner-close"]', { timeout: 3000 }) - } catch { - // Banner might not be present, continue test - } - - // Handle authentication state - const isLoggedIn = await page.locator('[data-testid="user-menu"]').isVisible() - if (!isLoggedIn) { - await page.click('[data-testid="login-link"]') - await page.fill('[data-testid="email"]', process.env.TEST_USER_EMAIL) - await page.fill('[data-testid="password"]', process.env.TEST_USER_PASSWORD) - await page.click('[data-testid="login-button"]') - } - - // Conditional workflows - const hasNotifications = await page.locator('[data-testid="notification-badge"]').isVisible() - if (hasNotifications) { - await page.click('[data-testid="notification-bell"]') - await page.click('[data-testid="mark-all-read"]') - } -}) -``` - -### 3. Mobile and Cross-Browser Optimization -Ensure tests work across different devices and browsers: - -```typescript -// Mobile-optimized testing -test('Mobile-responsive workflow', async ({ page }) => { - // Set mobile viewport - await page.setViewportSize({ width: 375, height: 812 }) - - await page.goto('https://app.example.com') - - // Mobile-specific interactions - await page.click('[data-testid="mobile-menu-toggle"]') - await expect(page.locator('[data-testid="mobile-nav"]')).toBeVisible() - - // Touch gestures simulation - const productCarousel = page.locator('[data-testid="product-carousel"]') - await productCarousel.hover() - - // Swipe gesture - const box = await productCarousel.boundingBox() - await page.mouse.move(box.x + box.width * 0.75, box.y + box.height / 2) - await page.mouse.down() - await page.mouse.move(box.x + box.width * 0.25, box.y + box.height / 2) - await page.mouse.up() - - // Mobile form interactions - await page.fill('[data-testid="search-input"]', 'test query') - await page.keyboard.press('Enter') // Mobile keyboard - - // Verify mobile-specific elements - await expect(page.locator('[data-testid="mobile-footer"]')).toBeVisible() -}) - -// Cross-browser compatibility patterns -const browserSpecificActions = { - chromium: async (page) => { - // Chrome-specific actions - await page.evaluate(() => { - if ('serviceWorker' in navigator) { - // Test service worker functionality - } - }) - }, - - webkit: async (page) => { - // Safari-specific considerations - await page.waitForTimeout(500) // Safari might be slower - }, - - firefox: async (page) => { - // Firefox-specific handling - await page.setExtraHTTPHeaders({ - 'User-Agent': 'Mozilla/5.0 Firefox' - }) - } -} -``` - -## Authentication and Session Management - -### 1. Efficient Authentication Strategies -Optimize authentication for test reliability and speed: - -```typescript -// Reusable authentication state -test.describe('Authenticated workflows', () => { - let authState - - test.beforeAll(async ({ browser }) => { - const page = await browser.newPage() - - // Perform login once - await page.goto('https://app.example.com/login') - await page.fill('[data-testid="email"]', process.env.TEST_USER_EMAIL) - await page.fill('[data-testid="password"]', process.env.TEST_USER_PASSWORD) - await page.click('[data-testid="login-button"]') - - // Wait for authentication to complete - await page.waitForSelector('[data-testid="user-dashboard"]') - - // Save authentication state - authState = await page.context().storageState() - await page.close() - }) - - test.beforeEach(async ({ page }) => { - // Reuse authentication state - await page.context().addInitScript(() => { - // Set authentication tokens if needed - localStorage.setItem('auth_token', 'test-token') - }) - }) - - test('User profile management', async ({ page }) => { - // User is already authenticated - await page.goto('https://app.example.com/profile') - await expect(page.locator('[data-testid="profile-form"]')).toBeVisible() - }) -}) - -// Multi-factor authentication handling -test('MFA authentication flow', async ({ page }) => { - await page.goto('https://app.example.com/login') - await page.fill('[data-testid="email"]', process.env.MFA_USER_EMAIL) - await page.fill('[data-testid="password"]', process.env.MFA_USER_PASSWORD) - await page.click('[data-testid="login-button"]') - - // Handle MFA prompt - await expect(page.locator('[data-testid="mfa-prompt"]')).toBeVisible() - - // In test environment, use predetermined MFA code - await page.fill('[data-testid="mfa-code"]', process.env.TEST_MFA_CODE) - await page.click('[data-testid="verify-mfa"]') - - // Verify successful authentication - await expect(page.locator('[data-testid="dashboard"]')).toBeVisible() -}) -``` - -### 2. Session and State Management -Handle user sessions and application state effectively: - -```typescript -// Session state management -test('Session persistence and recovery', async ({ page, context }) => { - // Set up initial session state - await context.addInitScript(() => { - // Simulate existing user session - localStorage.setItem('user_preferences', JSON.stringify({ - theme: 'dark', - language: 'en', - notifications: true - })) - - sessionStorage.setItem('cart_items', JSON.stringify([ - { id: 1, name: 'Product A', quantity: 2 } - ])) - }) - - await page.goto('https://app.example.com') - - // Verify session state is applied - await expect(page.locator('[data-testid="dark-theme"]')).toBeVisible() - await expect(page.locator('[data-testid="cart-count"]')).toContainText('2') - - // Test session timeout handling - await context.addInitScript(() => { - // Simulate expired session - localStorage.removeItem('auth_token') - }) - - // Navigate to protected page - await page.goto('https://app.example.com/protected') - - // Should redirect to login - await expect(page).toHaveURL(/.*login/) -}) -``` - -## Visual Testing and Validation - -### 1. Visual Regression Testing -Implement visual validation for UI consistency: - -```typescript -// Visual regression testing -test('Visual consistency validation', async ({ page }) => { - await page.goto('https://app.example.com') - - // Full page screenshot - await expect(page).toHaveScreenshot('homepage-full.png', { - fullPage: true, - threshold: 0.2 // Allow 20% difference - }) - - // Component-specific screenshots - await expect(page.locator('[data-testid="header"]')).toHaveScreenshot('header.png') - await expect(page.locator('[data-testid="footer"]')).toHaveScreenshot('footer.png') - - // Mobile visual testing - await page.setViewportSize({ width: 375, height: 812 }) - await expect(page).toHaveScreenshot('homepage-mobile.png') - - // Dark mode visual testing - await page.click('[data-testid="theme-toggle"]') - await expect(page).toHaveScreenshot('homepage-dark.png') -}) - -// Visual element validation -test('UI element visual validation', async ({ page }) => { - await page.goto('https://app.example.com/dashboard') - - // Verify specific visual elements - const chartElement = page.locator('[data-testid="analytics-chart"]') - await expect(chartElement).toBeVisible() - - // Color and style validation - const styles = await chartElement.evaluate((el) => { - const computed = window.getComputedStyle(el) - return { - backgroundColor: computed.backgroundColor, - borderColor: computed.borderColor, - fontSize: computed.fontSize - } - }) - - expect(styles.backgroundColor).toBe('rgb(255, 255, 255)') - expect(styles.fontSize).toBe('14px') -}) -``` - -### 2. Performance Monitoring Integration -Monitor Core Web Vitals and performance metrics: - -```typescript -// Performance monitoring in browser checks -test('Performance metrics validation', async ({ page }) => { - // Start performance monitoring - await page.goto('https://app.example.com', { waitUntil: 'networkidle' }) - - // Collect Core Web Vitals - const vitals = await page.evaluate(() => { - return new Promise((resolve) => { - const vitals = {} - - // Largest Contentful Paint - new PerformanceObserver((list) => { - const entries = list.getEntries() - vitals.lcp = entries[entries.length - 1].startTime - }).observe({ entryTypes: ['largest-contentful-paint'] }) - - // First Input Delay - new PerformanceObserver((list) => { - const entries = list.getEntries() - vitals.fid = entries[0].processingStart - entries[0].startTime - }).observe({ entryTypes: ['first-input'] }) - - // Cumulative Layout Shift - let clsValue = 0 - new PerformanceObserver((list) => { - for (const entry of list.getEntries()) { - if (!entry.hadRecentInput) { - clsValue += entry.value - } - } - vitals.cls = clsValue - }).observe({ entryTypes: ['layout-shift'] }) - - setTimeout(() => resolve(vitals), 5000) - }) - }) - - // Assert performance thresholds - expect(vitals.lcp).toBeLessThan(2500) // LCP < 2.5s - expect(vitals.fid).toBeLessThan(100) // FID < 100ms - expect(vitals.cls).toBeLessThan(0.1) // CLS < 0.1 - - // Custom performance metrics - const navigationTiming = await page.evaluate(() => { - const timing = performance.getEntriesByType('navigation')[0] - return { - domContentLoaded: timing.domContentLoadedEventEnd - timing.domContentLoadedEventStart, - loadComplete: timing.loadEventEnd - timing.loadEventStart, - timeToInteractive: timing.domInteractive - timing.navigationStart - } - }) - - expect(navigationTiming.domContentLoaded).toBeLessThan(1000) - expect(navigationTiming.timeToInteractive).toBeLessThan(3000) -}) -``` - -## Maintenance and Optimization - -### 1. Test Organization and Structure -Maintain clean, organized test suites: - -```typescript -// Organized test structure -test.describe('E-commerce Platform', () => { - test.describe('User Authentication', () => { - test('User login with valid credentials', async ({ page }) => { - // Test implementation - }) - - test('User login with invalid credentials', async ({ page }) => { - // Test implementation - }) - - test('Password reset workflow', async ({ page }) => { - // Test implementation - }) - }) - - test.describe('Shopping Cart', () => { - test.beforeEach(async ({ page }) => { - // Common setup for cart tests - await authenticateUser(page) - await addProductToCart(page) - }) - - test('Add product to cart', async ({ page }) => { - // Test implementation - }) - - test('Remove product from cart', async ({ page }) => { - // Test implementation - }) - }) -}) - -// Reusable helper functions -const authenticateUser = async (page) => { - await page.goto('https://app.example.com/login') - await page.fill('[data-testid="email"]', process.env.TEST_USER_EMAIL) - await page.fill('[data-testid="password"]', process.env.TEST_USER_PASSWORD) - await page.click('[data-testid="login-button"]') - await page.waitForSelector('[data-testid="user-dashboard"]') -} - -const addProductToCart = async (page) => { - await page.goto('https://app.example.com/products/test-product') - await page.click('[data-testid="add-to-cart"]') - await page.waitForSelector('[data-testid="cart-notification"]') -} -``` - -### 2. Environment and Configuration Management -Handle different environments and configurations: - -```typescript -// Environment-specific configuration -const config = { - development: { - baseUrl: 'https://dev.example.com', - timeout: 60000, - retries: 3 - }, - staging: { - baseUrl: 'https://staging.example.com', - timeout: 30000, - retries: 2 - }, - production: { - baseUrl: 'https://app.example.com', - timeout: 15000, - retries: 1 - } -} - -const env = process.env.NODE_ENV || 'production' -const currentConfig = config[env] - -test.use({ - baseURL: currentConfig.baseUrl, - timeout: currentConfig.timeout -}) - -// Feature flag handling -test('Feature flag dependent functionality', async ({ page }) => { - await page.goto('/') - - // Check if feature is enabled - const featureEnabled = await page.evaluate(() => { - return window.featureFlags?.newDashboard === true - }) - - if (featureEnabled) { - await expect(page.locator('[data-testid="new-dashboard"]')).toBeVisible() - } else { - await expect(page.locator('[data-testid="legacy-dashboard"]')).toBeVisible() - } -}) -``` - -### 3. Monitoring and Alerting Strategy -Configure effective monitoring for browser checks: - -```yaml -# Browser check monitoring strategy -Critical User Journeys: - frequency: Every 2 minutes - locations: [us-east-1, eu-west-1, ap-southeast-1] - thresholds: - response_time: 5000ms - success_rate: 95% - alerts: - immediate: true - channels: [slack, pagerduty, email] - -Standard User Workflows: - frequency: Every 10 minutes - locations: [us-east-1, eu-west-1] - thresholds: - response_time: 10000ms - success_rate: 90% - alerts: - after_failures: 2 - channels: [slack, email] - -Performance Monitoring: - core_web_vitals: true - thresholds: - lcp: 2500ms - fid: 100ms - cls: 0.1 - alerts: - degradation: 20% - duration: 30 minutes -``` - - - -Use Playwright's built-in debugging features like `page.pause()` and `--debug` mode during test development to understand and optimize your user journey tests. - \ No newline at end of file diff --git a/detect/uptime-monitoring/alerting.mdx b/detect/uptime-monitoring/alerting.mdx deleted file mode 100644 index 45821df5..00000000 --- a/detect/uptime-monitoring/alerting.mdx +++ /dev/null @@ -1,314 +0,0 @@ ---- -title: 'Alerting Configuration' -description: 'Configure comprehensive alerting for your uptime monitors to ensure your team is immediately notified when issues occur.' -sidebarTitle: 'Alerting' -canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/alerting/' ---- - -Effective alerting is crucial for maintaining service reliability. This guide covers how to configure alerting for all types of uptime monitors to ensure your team responds quickly to issues. - -## Alert Conditions - -Different monitor types trigger alerts based on specific failure conditions: - -### URL Monitor Alerts -- **HTTP errors** (4xx, 5xx status codes) -- **Response time threshold exceeded** -- **Content validation failed** -- **SSL certificate issues** -- **Network connectivity problems** - -### TCP Monitor Alerts -- **Connection failures** -- **Timeout exceeded** -- **Response validation failed** -- **SSL certificate issues** - -### Heartbeat Monitor Alerts -- **Missing pings** (no ping received within expected timeframe) -- **Grace period exceeded** - -## Alert Channels - -Configure multiple notification methods to ensure alerts reach the right people: - - - -Direct email alerts to individuals or distribution lists - - - -Team notifications in Slack channels with rich formatting - - - -Custom integrations with your existing tools and workflows - - - -Critical alerts via SMS for immediate attention (premium feature) - - - -### Advanced Integrations -- **PagerDuty** - On-call management and escalation -- **Microsoft Teams** - Team collaboration and notifications -- **Custom Webhooks** - Integration with ITSM, ChatOps, and monitoring tools - -## Alert Configuration Best Practices - -### Channel Selection by Severity - -**Low Priority Alerts:** -- Email notifications -- Slack channel for non-critical services -- No immediate action required - -**Medium Priority Alerts:** -- Email + Slack notifications -- Team channel notifications -- Action required during business hours - -**High Priority Alerts:** -- All channels (Email + Slack + SMS) -- PagerDuty escalation -- Immediate action required - -### Alert Timing and Frequency - -**Immediate Alerts:** -```yaml -Trigger: First failure detected -Channels: All configured channels -Use for: Critical production services -``` - -**Delayed Alerts:** -```yaml -Trigger: After 2-3 consecutive failures -Channels: Email, Slack -Use for: Less critical services to reduce noise -``` - -**Escalation Alerts:** -```yaml -Trigger: Issue unresolved after X minutes -Channels: SMS, PagerDuty -Use for: Critical services requiring guaranteed response -``` - -## Configuring Email Alerts - -Email alerts provide detailed information about monitor failures: - -### Email Content -- **Monitor name and type** -- **Failure reason and error details** -- **Affected locations** -- **Failure duration** -- **Direct links to monitor dashboard** - -### Email Configuration -```yaml -Recipients: team@company.com, oncall@company.com -Subject: "[ALERT] {monitor_name} is DOWN" -Format: HTML with detailed error information -Frequency: Immediate, then digest for ongoing issues -``` - -## Slack Integration - -Slack alerts provide real-time team notifications with interactive elements: - -### Slack Alert Features -- **Rich formatting** with monitor status and metrics -- **Quick actions** like acknowledge or view details -- **Thread updates** for ongoing incident tracking -- **Channel routing** based on monitor tags or criticality - -### Setup Example -```yaml -Channel: #monitoring-alerts -Message Format: - - Monitor name and status - - Error details and location - - Response time and availability metrics - - Quick action buttons -``` - -## Webhook Configuration - -Webhooks enable custom integrations with your existing tools: - -### Common Webhook Uses -- **ITSM Integration** - Automatically create service tickets -- **ChatOps** - Trigger automated response playbooks -- **Custom Dashboards** - Update internal status pages -- **Metrics Collection** - Feed data into analytics platforms - -### Webhook Payload Example -```json -{ - "monitor": { - "name": "Production API", - "type": "url_monitor", - "id": "monitor_123" - }, - "alert": { - "type": "monitor_failure", - "timestamp": "2024-01-15T10:30:00Z", - "message": "HTTP 500 Internal Server Error" - }, - "check_result": { - "status_code": 500, - "response_time": 5000, - "location": "us-east-1" - } -} -``` - -## Alert Management - -### Alert Acknowledgment -- **Manual Acknowledgment** - Team members can acknowledge alerts -- **Auto-Acknowledgment** - Automatic acknowledgment when issues resolve -- **Escalation Rules** - Escalate unacknowledged alerts after time periods - -### Alert Suppression -- **Maintenance Windows** - Suppress alerts during planned maintenance -- **Alert Grouping** - Combine related alerts to reduce noise -- **Rate Limiting** - Prevent alert flooding during widespread outages - -### Alert History -- **Timeline View** - See all alerts and resolutions over time -- **Alert Analytics** - Track mean time to resolution and alert frequency -- **Team Performance** - Monitor response times and acknowledgment rates - -## Advanced Alerting Strategies - -### Multi-Location Alerting - -**Regional Failures:** -```yaml -Condition: 1+ locations in same region failing -Action: Email notification to regional team -Escalation: If multiple regions affected -``` - -**Global Outages:** -```yaml -Condition: 3+ locations across regions failing -Action: Immediate SMS + PagerDuty -Escalation: Executive notification after 15 minutes -``` - -### Conditional Alerting - -**Business Hours vs. After Hours:** -```yaml -Business Hours (9 AM - 6 PM): - - Email + Slack notifications - - 30-minute escalation to manager - -After Hours: - - Immediate SMS to on-call engineer - - 15-minute escalation to backup -``` - -**Service Criticality:** -```yaml -Critical Services: - - Immediate multi-channel alerts - - No delay or batching - -Non-Critical Services: - - Email alerts only - - 15-minute delay for transient issues -``` - -### Performance Degradation Alerts - -Monitor performance trends and alert on degradation: - -```yaml -Warning Threshold: Response time > 2x baseline -Critical Threshold: Response time > 5x baseline -Duration: Sustained for 5+ minutes -Action: Graduated alerts based on severity -``` - -## Alert Testing and Validation - -### Regular Testing -- **Test all alert channels monthly** -- **Verify escalation rules work correctly** -- **Confirm contact information is current** -- **Validate webhook integrations** - -### Alert Simulation -```bash -# Test webhook endpoint -curl -X POST https://your-webhook-url.com/alerts \ - -H "Content-Type: application/json" \ - -d '{"test": true, "monitor": "test-monitor"}' -``` - -## Troubleshooting Common Alert Issues - -### Missing Alerts - -**Symptoms:** -- Service is down but no alerts received -- Alerts delayed or inconsistent - -**Solutions:** -1. Check alert channel configuration -2. Verify contact information is current -3. Test alert delivery manually -4. Review alert suppression settings - -### Alert Fatigue - -**Symptoms:** -- Too many false positive alerts -- Team ignoring or delaying responses -- Alert acknowledgment rates dropping - -**Solutions:** -1. Adjust alert thresholds and timing -2. Implement alert grouping and rate limiting -3. Use maintenance windows during deployments -4. Regular review and tuning of alert rules - -### Integration Failures - -**Symptoms:** -- Slack/webhook alerts not delivering -- PagerDuty escalations not working -- Email alerts in spam folders - -**Solutions:** -1. Verify integration credentials and permissions -2. Check webhook endpoint availability -3. Review email filtering and whitelist settings -4. Test integrations regularly - -## Next Steps - - - -Configure optimal monitoring locations for accurate global coverage - - - -Set up monitoring frequency and timing strategies - - - -Detailed configuration for specific alert channel types - - - -Configure retry strategies to reduce false positive alerts - - diff --git a/detect/uptime-monitoring/cli-configuration.mdx b/detect/uptime-monitoring/cli-configuration.mdx deleted file mode 100644 index bbc0dbab..00000000 --- a/detect/uptime-monitoring/cli-configuration.mdx +++ /dev/null @@ -1,685 +0,0 @@ ---- -title: 'CLI Configuration' -description: 'Define and manage uptime monitors as code using the Checkly CLI with TypeScript and JavaScript examples.' -sidebarTitle: 'CLI Configuration' -canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/cli-configuration/' ---- - -The Checkly CLI enables you to define, version control, and deploy uptime monitors as code. This approach provides better maintainability, team collaboration, and integration with your development workflow. - -## Getting Started with CLI - -### Installation - -Install the Checkly CLI in your project: - -```bash -npm install --save-dev checkly -``` - -### Project Setup - -Initialize a new Checkly project: - -```bash -npx checkly init -``` - -This creates the basic project structure with configuration files and example monitors. - -## URL Monitor Configuration - -### Basic URL Monitor - - - -```ts url-monitor.check.ts -import { Frequency, UrlMonitor, UrlAssertionBuilder } from 'checkly/constructs' - -new UrlMonitor('homepage-check', { - name: 'Homepage Availability', - activated: true, - locations: ['us-east-1', 'eu-west-1', 'ap-southeast-1'], - frequency: Frequency.EVERY_5M, - maxResponseTime: 2000, // ms - request: { - url: 'https://www.myapp.com', - assertions: [ - UrlAssertionBuilder.statusCode().equals(200), - ] - }, - tags: ['production', 'frontend', 'critical'] -}) -``` - -```js url-monitor.check.js -const { Frequency, UrlMonitor, UrlAssertionBuilder } = require('checkly/constructs') - -new UrlMonitor('homepage-check', { - name: 'Homepage Availability', - activated: true, - locations: ['us-east-1', 'eu-west-1', 'ap-southeast-1'], - frequency: Frequency.EVERY_5M, - maxResponseTime: 2000, // ms - request: { - url: 'https://www.myapp.com', - assertions: [ - UrlAssertionBuilder.statusCode().equals(200), - ] - }, - tags: ['production', 'frontend', 'critical'] -}) -``` - - - -### Advanced URL Monitor with Response Time Limits - -URL monitors only assert on the HTTP status code. If you need to send custom headers or assert on the response body, use an [API check](/detect/synthetic-monitoring/api-checks/overview) instead. - -The samples on this page define their alert channels inline to stay self-contained. In a real project, define each [alert channel](/constructs/alert-channel) once in a shared file, export it, and import it where needed; a logical ID may only be used once per project. - - - -```ts api-monitor.check.ts -import { Frequency, UrlMonitor, UrlAssertionBuilder, EmailAlertChannel, SlackAppAlertChannel } from 'checkly/constructs' - -const emailAlerts = new EmailAlertChannel('email-alerts', { - address: 'ops@myapp.com' -}) -const slackAlerts = new SlackAppAlertChannel('slack-alerts', { - slackChannels: ['#alerts'] -}) - -new UrlMonitor('api-health-check', { - name: 'API Health Check', - activated: true, - locations: ['us-east-1', 'eu-west-1'], - frequency: Frequency.EVERY_2M, - degradedResponseTime: 500, // ms - maxResponseTime: 1000, // ms - request: { - url: 'https://api.myapp.com/health', - assertions: [ - UrlAssertionBuilder.statusCode().equals(200), - ] - }, - alertChannels: [emailAlerts, slackAlerts], - tags: ['production', 'api', 'critical'] -}) -``` - -```js api-monitor.check.js -const { Frequency, UrlMonitor, UrlAssertionBuilder, EmailAlertChannel, SlackAppAlertChannel } = require('checkly/constructs') - -const emailAlerts = new EmailAlertChannel('email-alerts', { - address: 'ops@myapp.com' -}) -const slackAlerts = new SlackAppAlertChannel('slack-alerts', { - slackChannels: ['#alerts'] -}) - -new UrlMonitor('api-health-check', { - name: 'API Health Check', - activated: true, - locations: ['us-east-1', 'eu-west-1'], - frequency: Frequency.EVERY_2M, - degradedResponseTime: 500, // ms - maxResponseTime: 1000, // ms - request: { - url: 'https://api.myapp.com/health', - assertions: [ - UrlAssertionBuilder.statusCode().equals(200), - ] - }, - alertChannels: [emailAlerts, slackAlerts], - tags: ['production', 'api', 'critical'] -}) -``` - - - -## TCP Monitor Configuration - -### Basic TCP Monitor - - - -```ts database-monitor.check.ts -import { Frequency, TcpMonitor } from 'checkly/constructs' - -new TcpMonitor('database-tcp-check', { - name: 'Production Database Connection', - activated: true, - locations: ['us-east-1', 'eu-west-1'], - frequency: Frequency.EVERY_5M, - degradedResponseTime: 3000, // ms - request: { - hostname: 'db.myapp.com', - port: 5432 - }, - tags: ['production', 'database', 'infrastructure'] -}) -``` - -```js database-monitor.check.js -const { Frequency, TcpMonitor } = require('checkly/constructs') - -new TcpMonitor('database-tcp-check', { - name: 'Production Database Connection', - activated: true, - locations: ['us-east-1', 'eu-west-1'], - frequency: Frequency.EVERY_5M, - degradedResponseTime: 3000, // ms - request: { - hostname: 'db.myapp.com', - port: 5432 - }, - tags: ['production', 'database', 'infrastructure'] -}) -``` - - - -### TCP Monitor with Response Validation - - - -```ts mail-server-monitor.check.ts -import { Frequency, TcpMonitor, TcpAssertionBuilder } from 'checkly/constructs' - -new TcpMonitor('mail-server-check', { - name: 'SMTP Server Monitoring', - activated: true, - locations: ['us-east-1', 'eu-west-1'], - frequency: Frequency.EVERY_10M, - degradedResponseTime: 3000, // ms - request: { - hostname: 'mail.myapp.com', - port: 587, - assertions: [ - // The SMTP server greets with a "220" banner on connect - TcpAssertionBuilder.responseData().contains('220'), - ] - }, - tags: ['production', 'mail', 'infrastructure'] -}) -``` - -```js mail-server-monitor.check.js -const { Frequency, TcpMonitor, TcpAssertionBuilder } = require('checkly/constructs') - -new TcpMonitor('mail-server-check', { - name: 'SMTP Server Monitoring', - activated: true, - locations: ['us-east-1', 'eu-west-1'], - frequency: Frequency.EVERY_10M, - degradedResponseTime: 3000, // ms - request: { - hostname: 'mail.myapp.com', - port: 587, - assertions: [ - // The SMTP server greets with a "220" banner on connect - TcpAssertionBuilder.responseData().contains('220'), - ] - }, - tags: ['production', 'mail', 'infrastructure'] -}) -``` - - - -## Heartbeat Monitor Configuration - -### Basic Heartbeat Monitor - - - -```ts backup-heartbeat.check.ts -import { HeartbeatMonitor } from 'checkly/constructs' - -new HeartbeatMonitor('daily-backup-heartbeat', { - name: 'Daily Database Backup', - activated: true, - period: 24, - periodUnit: 'hours', - grace: 30, // 30 minutes grace period - graceUnit: 'minutes', - tags: ['backup', 'database', 'daily'] -}) -``` - -```js backup-heartbeat.check.js -const { HeartbeatMonitor } = require('checkly/constructs') - -new HeartbeatMonitor('daily-backup-heartbeat', { - name: 'Daily Database Backup', - activated: true, - period: 24, - periodUnit: 'hours', - grace: 30, // 30 minutes grace period - graceUnit: 'minutes', - tags: ['backup', 'database', 'daily'] -}) -``` - - - -### Heartbeat Monitor with Custom Configuration - - - -```ts sync-job-heartbeat.check.ts -import { HeartbeatMonitor, PagerdutyAlertChannel, SlackAppAlertChannel } from 'checkly/constructs' - -const pagerdutyCritical = new PagerdutyAlertChannel('pagerduty-critical', { - serviceName: 'Data platform', - serviceKey: 'your-pagerduty-integration-key' -}) -const slackOps = new SlackAppAlertChannel('slack-ops', { - slackChannels: ['#ops'] -}) - -new HeartbeatMonitor('hourly-sync-heartbeat', { - name: 'Hourly Data Sync Job', - activated: true, - period: 1, - periodUnit: 'hours', - grace: 10, // 10 minutes grace period - graceUnit: 'minutes', - alertChannels: [pagerdutyCritical, slackOps], - tags: ['sync', 'data', 'hourly', 'critical'] -}) -``` - -```js sync-job-heartbeat.check.js -const { HeartbeatMonitor, PagerdutyAlertChannel, SlackAppAlertChannel } = require('checkly/constructs') - -const pagerdutyCritical = new PagerdutyAlertChannel('pagerduty-critical', { - serviceName: 'Data platform', - serviceKey: 'your-pagerduty-integration-key' -}) -const slackOps = new SlackAppAlertChannel('slack-ops', { - slackChannels: ['#ops'] -}) - -new HeartbeatMonitor('hourly-sync-heartbeat', { - name: 'Hourly Data Sync Job', - activated: true, - period: 1, - periodUnit: 'hours', - grace: 10, // 10 minutes grace period - graceUnit: 'minutes', - alertChannels: [pagerdutyCritical, slackOps], - tags: ['sync', 'data', 'hourly', 'critical'] -}) -``` - - - -## Shared Configuration and Groups - -### Monitor Groups - -Organize related monitors using groups: - - - -```ts api-monitoring-group.check.ts -import { Frequency, CheckGroupV2, UrlMonitor, EmailAlertChannel, SlackAppAlertChannel } from 'checkly/constructs' - -const emailAlerts = new EmailAlertChannel('email-alerts', { - address: 'ops@myapp.com' -}) -const slackApiAlerts = new SlackAppAlertChannel('slack-api-alerts', { - slackChannels: ['#api-alerts'] -}) - -const apiGroup = new CheckGroupV2('api-monitoring', { - name: 'API Monitoring', - activated: true, - locations: ['us-east-1', 'eu-west-1', 'ap-southeast-1'], - frequency: Frequency.EVERY_5M, - alertChannels: [emailAlerts, slackApiAlerts], - tags: ['api', 'production'] -}) - -// Monitors inherit group settings -new UrlMonitor('users-api', { - name: 'Users API', - group: apiGroup, - request: { - url: 'https://api.myapp.com/users' - } -}) - -new UrlMonitor('orders-api', { - name: 'Orders API', - group: apiGroup, - request: { - url: 'https://api.myapp.com/orders' - } -}) -``` - -```js api-monitoring-group.check.js -const { Frequency, CheckGroupV2, UrlMonitor, EmailAlertChannel, SlackAppAlertChannel } = require('checkly/constructs') - -const emailAlerts = new EmailAlertChannel('email-alerts', { - address: 'ops@myapp.com' -}) -const slackApiAlerts = new SlackAppAlertChannel('slack-api-alerts', { - slackChannels: ['#api-alerts'] -}) - -const apiGroup = new CheckGroupV2('api-monitoring', { - name: 'API Monitoring', - activated: true, - locations: ['us-east-1', 'eu-west-1', 'ap-southeast-1'], - frequency: Frequency.EVERY_5M, - alertChannels: [emailAlerts, slackApiAlerts], - tags: ['api', 'production'] -}) - -// Monitors inherit group settings -new UrlMonitor('users-api', { - name: 'Users API', - group: apiGroup, - request: { - url: 'https://api.myapp.com/users' - } -}) - -new UrlMonitor('orders-api', { - name: 'Orders API', - group: apiGroup, - request: { - url: 'https://api.myapp.com/orders' - } -}) -``` - - - -### Environment Variables - -Use environment variables to vary the configuration per environment: - - - -```ts environment-config.check.ts -import { Frequency, UrlMonitor, UrlAssertionBuilder } from 'checkly/constructs' - -// Environment-specific configuration -const baseUrl = process.env.BASE_URL || 'https://api.myapp.com' -const environment = process.env.ENVIRONMENT || 'production' - -new UrlMonitor(`${environment}-api-check`, { - name: `${environment.toUpperCase()} API Health`, - activated: environment === 'production', - locations: environment === 'production' - ? ['us-east-1', 'eu-west-1', 'ap-southeast-1'] - : ['us-east-1'], - frequency: environment === 'production' ? Frequency.EVERY_2M : Frequency.EVERY_10M, - maxResponseTime: environment === 'production' ? 2000 : 5000, // ms - request: { - url: `${baseUrl}/health`, - assertions: [ - UrlAssertionBuilder.statusCode().equals(200), - ] - }, - tags: [environment, 'api', 'health'] -}) -``` - -```js environment-config.check.js -const { Frequency, UrlMonitor, UrlAssertionBuilder } = require('checkly/constructs') - -// Environment-specific configuration -const baseUrl = process.env.BASE_URL || 'https://api.myapp.com' -const environment = process.env.ENVIRONMENT || 'production' - -new UrlMonitor(`${environment}-api-check`, { - name: `${environment.toUpperCase()} API Health`, - activated: environment === 'production', - locations: environment === 'production' - ? ['us-east-1', 'eu-west-1', 'ap-southeast-1'] - : ['us-east-1'], - frequency: environment === 'production' ? Frequency.EVERY_2M : Frequency.EVERY_10M, - maxResponseTime: environment === 'production' ? 2000 : 5000, // ms - request: { - url: `${baseUrl}/health`, - assertions: [ - UrlAssertionBuilder.statusCode().equals(200), - ] - }, - tags: [environment, 'api', 'health'] -}) -``` - - - -## Deployment and CI/CD Integration - -### Deploying Monitors - -Deploy your monitors to Checkly: - -```bash -# Deploy all monitors -npx checkly deploy - -# Deploy with environment variables -ENVIRONMENT=production BASE_URL=https://api.myapp.com npx checkly deploy - -# Test before deploying -npx checkly test - -# Preview changes -npx checkly deploy --preview -``` - -### GitHub Actions Integration - -Example GitHub Actions workflow: - -```yaml .github/workflows/checkly.yml -name: Deploy Checkly Monitors - -on: - push: - branches: [main] - paths: ['monitoring/**'] - -jobs: - deploy-monitoring: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v3 - - - name: Setup Node.js - uses: actions/setup-node@v3 - with: - node-version: '22' - cache: 'npm' - - - name: Install dependencies - run: npm ci - - - name: Test monitors - run: npx checkly test - env: - CHECKLY_API_KEY: ${{ secrets.CHECKLY_API_KEY }} - CHECKLY_ACCOUNT_ID: ${{ vars.CHECKLY_ACCOUNT_ID }} - - - name: Deploy monitors - run: npx checkly deploy - env: - CHECKLY_API_KEY: ${{ secrets.CHECKLY_API_KEY }} - CHECKLY_ACCOUNT_ID: ${{ vars.CHECKLY_ACCOUNT_ID }} - ENVIRONMENT: production - BASE_URL: https://api.myapp.com -``` - -## Advanced Patterns - -### Dynamic Monitor Generation - -Generate monitors programmatically: - - - -```ts dynamic-monitors.check.ts -import { Frequency, UrlMonitor, UrlAssertionBuilder } from 'checkly/constructs' - -// Monitor multiple API endpoints -const endpoints = [ - { path: '/users', name: 'Users API' }, - { path: '/orders', name: 'Orders API' }, - { path: '/products', name: 'Products API' }, - { path: '/payments', name: 'Payments API' } -] - -endpoints.forEach((endpoint, index) => { - new UrlMonitor(`api-${endpoint.path.replace('/', '')}-check`, { - name: endpoint.name, - activated: true, - locations: ['us-east-1', 'eu-west-1'], - frequency: endpoint.path === '/payments' ? Frequency.EVERY_1M : Frequency.EVERY_5M, // More frequent for critical endpoints - maxResponseTime: endpoint.path === '/payments' ? 500 : 1000, // Stricter limit for critical endpoints - request: { - url: `https://api.myapp.com${endpoint.path}`, - assertions: [ - UrlAssertionBuilder.statusCode().equals(200), - ] - }, - tags: ['api', 'production', endpoint.path.replace('/', '')] - }) -}) -``` - -```js dynamic-monitors.check.js -const { Frequency, UrlMonitor, UrlAssertionBuilder } = require('checkly/constructs') - -// Monitor multiple API endpoints -const endpoints = [ - { path: '/users', name: 'Users API' }, - { path: '/orders', name: 'Orders API' }, - { path: '/products', name: 'Products API' }, - { path: '/payments', name: 'Payments API' } -] - -endpoints.forEach((endpoint, index) => { - new UrlMonitor(`api-${endpoint.path.replace('/', '')}-check`, { - name: endpoint.name, - activated: true, - locations: ['us-east-1', 'eu-west-1'], - frequency: endpoint.path === '/payments' ? Frequency.EVERY_1M : Frequency.EVERY_5M, // More frequent for critical endpoints - maxResponseTime: endpoint.path === '/payments' ? 500 : 1000, // Stricter limit for critical endpoints - request: { - url: `https://api.myapp.com${endpoint.path}`, - assertions: [ - UrlAssertionBuilder.statusCode().equals(200), - ] - }, - tags: ['api', 'production', endpoint.path.replace('/', '')] - }) -}) -``` - - - -### Configuration Management - -Centralized configuration management: - - - -```ts config/monitoring.ts -interface MonitoringConfig { - baseUrl: string - locations: string[] - defaultFrequency: number - environment: string -} - -export const config: MonitoringConfig = { - baseUrl: process.env.BASE_URL || 'https://api.myapp.com', - locations: process.env.ENVIRONMENT === 'production' - ? ['us-east-1', 'eu-west-1', 'ap-southeast-1'] - : ['us-east-1'], - defaultFrequency: process.env.ENVIRONMENT === 'production' ? 5 : 15, - environment: process.env.ENVIRONMENT || 'development' -} -``` - -```js config/monitoring.js -const config = { - baseUrl: process.env.BASE_URL || 'https://api.myapp.com', - locations: process.env.ENVIRONMENT === 'production' - ? ['us-east-1', 'eu-west-1', 'ap-southeast-1'] - : ['us-east-1'], - defaultFrequency: process.env.ENVIRONMENT === 'production' ? 5 : 15, - environment: process.env.ENVIRONMENT || 'development' -} - -module.exports = { config } -``` - - - -## Best Practices - -### Project Organization -``` -monitoring/ -├── config/ -│ └── monitoring.ts -├── monitors/ -│ ├── api/ -│ │ ├── users-api.check.ts -│ │ └── orders-api.check.ts -│ ├── infrastructure/ -│ │ ├── database.check.ts -│ │ └── redis.check.ts -│ └── heartbeats/ -│ ├── backup-jobs.check.ts -│ └── sync-jobs.check.ts -├── groups/ -│ ├── api-group.ts -│ └── infrastructure-group.ts -├── alert-channels.ts -└── checkly.config.ts -``` - -### Version Control -- **Commit monitor changes** with descriptive messages -- **Use branch protection** for production monitor deployments -- **Review monitor changes** before merging to main branch -- **Tag releases** for monitor configuration versions - -### Testing and Validation -- **Test monitors locally** before deployment -- **Use preview deployments** to validate changes -- **Monitor the monitors** - track deployment success -- **Rollback capabilities** for failed deployments - -## Next Steps - - - -Configure alert channels and notification rules for your CLI-managed monitors - - - -Understand frequency and timing options for different monitor types - - - -Complete API reference for all monitor types and configuration options - - - -Advanced CI/CD patterns and deployment strategies - - diff --git a/detect/uptime-monitoring/heartbeat-monitors/ci-cd-configuration.mdx b/detect/uptime-monitoring/heartbeat-monitors/ci-cd-configuration.mdx deleted file mode 100644 index bc1769c2..00000000 --- a/detect/uptime-monitoring/heartbeat-monitors/ci-cd-configuration.mdx +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: 'CI/CD Configuration' -description: 'Learn how to configure heartbeat monitors with CI/CD.' -sidebarTitle: CI/CD -canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/heartbeat-monitors/ci-cd-configuration/' ---- - - -## With CI/CD Pipelines - -Integrate heartbeat monitoring into your CI/CD pipelines to monitor deployment processes and post-deployment verification. - -### GitHub Actions Example - -```yaml -name: Deploy and Monitor -on: - push: - branches: [main] - -jobs: - deploy: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v3 - - - name: Deploy to production - run: | - # Your deployment steps - echo "Deploying to production..." - - - name: Ping heartbeat after deployment - run: | - curl -m 5 --retry 3 ${{ secrets.HEARTBEAT_URL }} - env: - HEARTBEAT_URL: ${{ secrets.DEPLOYMENT_HEARTBEAT_URL }} -``` - -### GitLab CI Example - -```yaml -stages: - - deploy - - verify - -deploy: - stage: deploy - script: - - echo "Deploying application..." - - # Your deployment commands - after_script: - - curl -m 5 --retry 3 $DEPLOYMENT_HEARTBEAT_URL - -verify: - stage: verify - script: - - echo "Running post-deployment checks..." - - # Your verification steps - after_script: - - curl -m 5 --retry 3 $VERIFICATION_HEARTBEAT_URL -``` - -### Jenkins Pipeline Example - -```groovy -pipeline { - agent any - - environment { - HEARTBEAT_URL = 'https://ping.checklyhq.com/your-deployment-id' - } - - stages { - stage('Deploy') { - steps { - echo 'Deploying to production...' - // Your deployment steps - } - post { - success { - sh 'curl -m 5 --retry 3 $HEARTBEAT_URL' - } - } - } - } -} -``` - diff --git a/detect/uptime-monitoring/heartbeat-monitors/cli-configuration.mdx b/detect/uptime-monitoring/heartbeat-monitors/cli-configuration.mdx deleted file mode 100644 index 94ca163f..00000000 --- a/detect/uptime-monitoring/heartbeat-monitors/cli-configuration.mdx +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: 'CLI Configuration' -description: 'Learn how to configure heartbeat monitors with the Checkly CLI.' -sidebarTitle: CLI -canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/heartbeat-monitors/cli-configuration/' ---- - - -## Overview - -The Checkly CLI is a powerful tool for managing your heartbeat monitors. It allows you to define your heartbeat monitors as code alongside your other monitoring, providing version control, code review, and consistent deployment across environments. - - - -## With the Checkly CLI - -Define heartbeat monitors as code alongside your other monitoring using the Checkly CLI. This approach provides version control, code review, and consistent deployment across environments. - -### TypeScript Example - -```typescript -import { HeartbeatMonitor } from 'checkly/constructs' - -new HeartbeatMonitor('weekly-newsletter', { - name: 'Weekly Newsletter Campaign', - period: 7, - periodUnit: 'days', - grace: 4, - graceUnit: 'hours', - tags: ['newsletter', 'marketing', 'weekly'] -}) - -new HeartbeatMonitor('database-backup', { - name: 'Nightly Database Backup', - period: 1, - periodUnit: 'days', - grace: 30, - graceUnit: 'minutes', - tags: ['backup', 'database', 'critical'] -}) -``` - -### JavaScript Example - -```javascript -const { HeartbeatMonitor } = require('checkly/constructs') - -new HeartbeatMonitor('data-sync', { - name: 'Hourly Data Sync', - period: 1, - periodUnit: 'hours', - grace: 10, - graceUnit: 'minutes', - tags: ['sync', 'data', 'hourly'] -}) -``` - -### Advanced CLI Configuration - -```typescript -import { HeartbeatMonitor, EmailAlertChannel, SlackAppAlertChannel } from 'checkly/constructs' - -const email = new EmailAlertChannel('email', { - address: 'ops@example.com' -}) -const slackCritical = new SlackAppAlertChannel('slack-critical', { - slackChannels: ['#critical'] -}) - -new HeartbeatMonitor('production-backup', { - name: 'Production Database Backup', - period: 24, - periodUnit: 'hours', - grace: 60, - graceUnit: 'minutes', - tags: ['production', 'backup', 'critical'], - alertChannels: [email, slackCritical], - activated: true, - muted: false -}) -``` - diff --git a/detect/uptime-monitoring/heartbeat-monitors/cron-configuration.mdx b/detect/uptime-monitoring/heartbeat-monitors/cron-configuration.mdx deleted file mode 100644 index 57d09130..00000000 --- a/detect/uptime-monitoring/heartbeat-monitors/cron-configuration.mdx +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: 'Cron Jobs Configuration' -description: 'Learn how to configure heartbeat monitors with cron jobs.' -sidebarTitle: Cron Jobs -canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/heartbeat-monitors/cron-configuration/' ---- - -## With Scheduled Jobs and Cron - -Monitor your existing cron jobs and scheduled tasks by adding heartbeat pings to their success paths. - -### Linux/Unix Cron Example - -```bash -# /etc/crontab -# Daily backup at 2 AM with heartbeat monitoring -0 2 * * * /usr/local/bin/backup.sh - -# /usr/local/bin/backup.sh -#!/bin/bash -set -e - -# Run backup -pg_dump mydb > /backups/backup-$(date +%Y%m%d).sql -aws s3 cp /backups/backup-$(date +%Y%m%d).sql s3://my-backup-bucket/ - -# Ping heartbeat only if backup succeeded -curl -m 5 --retry 3 https://ping.checklyhq.com/your-backup-heartbeat-id -``` - -### Windows Task Scheduler Example - -```batch -@echo off -REM backup.bat -echo Starting backup... - -REM Run backup commands -pg_dump mydb > backup.sql -aws s3 cp backup.sql s3://my-backup-bucket/ - -REM Ping heartbeat on success -curl -m 5 --retry 3 https://ping.checklyhq.com/your-backup-heartbeat-id -``` - -### Systemd Timer Example - -```ini -# /etc/systemd/system/backup.service -[Unit] -Description=Daily Database Backup -After=network.target - -[Service] -Type=oneshot -ExecStart=/usr/local/bin/backup.sh -User=backup -Group=backup - -# /etc/systemd/system/backup.timer -[Unit] -Description=Run backup daily at 2 AM -Requires=backup.service - -[Timer] -OnCalendar=*-*-* 02:00:00 -Persistent=true - -[Install] -WantedBy=timers.target -``` - diff --git a/detect/uptime-monitoring/heartbeat-monitors/iac-configuration.mdx b/detect/uptime-monitoring/heartbeat-monitors/iac-configuration.mdx deleted file mode 100644 index 3b7e4b9c..00000000 --- a/detect/uptime-monitoring/heartbeat-monitors/iac-configuration.mdx +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: 'Infrastructure as Code Configuration' -description: 'Learn how to configure heartbeat monitors with Infrastructure as Code.' -sidebarTitle: Infrastructure as Code -canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/heartbeat-monitors/iac-configuration/' ---- - - -## Overview - -IaC is a common way to configure heartbeat monitors. They are a simple way to ensure that your heartbeat monitors are running at a specific time. - -## With Infrastructure as Code - -Many teams manage heartbeat monitors alongside their infrastructure using tools like Terraform, ensuring monitoring is created when new scheduled jobs are deployed. - -### Terraform Example - -```hcl -resource "checkly_heartbeat" "daily_backup" { - name = "Daily Database Backup" - period = 24 - period_unit = "hours" - grace = 30 - grace_unit = "minutes" - tags = ["backup", "database", "daily"] - - alert_channels = [ - checkly_alert_channel.email.id, - checkly_alert_channel.slack.id - ] -} - -resource "checkly_heartbeat" "weekly_reports" { - name = "Weekly Analytics Reports" - period = 168 # 7 days in hours - period_unit = "hours" - grace = 240 # 4 hours in minutes - grace_unit = "minutes" - tags = ["reports", "analytics", "weekly"] -} -``` - -### AWS CloudFormation Example - -```yaml -Resources: - HeartbeatMonitor: - Type: AWS::CloudFormation::CustomResource - Properties: - ServiceToken: !GetAtt HeartbeatFunction.Arn - Name: "Daily Backup Monitor" - Period: 24 - PeriodUnit: "hours" - Grace: 30 - GraceUnit: "minutes" - Tags: ["backup", "daily"] -``` diff --git a/detect/uptime-monitoring/heartbeat-monitors/other.mdx b/detect/uptime-monitoring/heartbeat-monitors/other.mdx deleted file mode 100644 index 8c3a3449..00000000 --- a/detect/uptime-monitoring/heartbeat-monitors/other.mdx +++ /dev/null @@ -1,320 +0,0 @@ ---- -title: 'Other Configurations' -description: 'Learn how to configure heartbeat monitors with other tools and platforms.' -sidebarTitle: Other Configurations -canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/heartbeat-monitors/other/' ---- - - -## With Cloud Platforms - -Integrate heartbeat monitoring with cloud platform services for comprehensive monitoring coverage. - -### AWS Lambda Example - -```python -import boto3 -import requests -import os - -def lambda_handler(event, context): - try: - # Your scheduled task logic - process_data() - - # Ping heartbeat on success - heartbeat_url = os.environ['HEARTBEAT_URL'] - requests.get(heartbeat_url, timeout=5) - - return { - 'statusCode': 200, - 'body': 'Task completed successfully' - } - except Exception as e: - # Don't ping on failure - let heartbeat alert - raise e - -def process_data(): - # Your actual task logic here - pass -``` - -### Google Cloud Functions Example - -```python -import requests -import os - -def process_scheduled_task(event, context): - try: - # Your scheduled task logic - generate_reports() - - # Ping heartbeat on success - heartbeat_url = os.environ.get('HEARTBEAT_URL') - if heartbeat_url: - requests.get(heartbeat_url, timeout=5) - - except Exception as e: - # Log error but don't ping - let heartbeat alert - print(f"Task failed: {e}") - raise e - -def generate_reports(): - # Your actual task logic here - pass -``` - -### Azure Functions Example - -```csharp -using System; -using System.Net.Http; -using System.Threading.Tasks; -using Microsoft.Azure.WebJobs; -using Microsoft.Extensions.Logging; - -public class ScheduledTask -{ - [FunctionName("ScheduledTask")] - public async Task Run( - [TimerTrigger("0 0 2 * * *")] TimerInfo myTimer, - ILogger log) - { - try - { - // Your scheduled task logic - await ProcessData(); - - // Ping heartbeat on success - var heartbeatUrl = Environment.GetEnvironmentVariable("HEARTBEAT_URL"); - if (!string.IsNullOrEmpty(heartbeatUrl)) - { - using (var client = new HttpClient()) - { - await client.GetAsync(heartbeatUrl); - } - } - } - catch (Exception ex) - { - // Don't ping on failure - let heartbeat alert - log.LogError(ex, "Task failed"); - throw; - } - } - - private async Task ProcessData() - { - // Your actual task logic here - } -} -``` - -## With Container Orchestration - -Monitor containerized applications and batch jobs in Kubernetes and Docker environments. - -### Kubernetes CronJob Example - -```yaml -apiVersion: batch/v1 -kind: CronJob -metadata: - name: daily-backup -spec: - schedule: "0 2 * * *" - jobTemplate: - spec: - template: - spec: - containers: - - name: backup - image: postgres:13 - command: - - /bin/bash - - -c - - | - # Run backup - pg_dump $DB_URL > /backups/backup.sql - aws s3 cp /backups/backup.sql s3://my-backup-bucket/ - - # Ping heartbeat on success - curl -m 5 --retry 3 $HEARTBEAT_URL - env: - - name: HEARTBEAT_URL - value: "https://ping.checklyhq.com/your-backup-id" - - name: DB_URL - valueFrom: - secretKeyRef: - name: db-secret - key: url - restartPolicy: OnFailure -``` - -### Docker Compose Example - -```yaml -version: '3.8' -services: - backup: - image: postgres:13 - command: | - bash -c " - # Run backup - pg_dump $$DB_URL > /backups/backup.sql - aws s3 cp /backups/backup.sql s3://my-backup-bucket/ - - # Ping heartbeat on success - curl -m 5 --retry 3 $$HEARTBEAT_URL - " - environment: - - HEARTBEAT_URL=https://ping.checklyhq.com/your-backup-id - - DB_URL=${DB_URL} - volumes: - - ./backups:/backups -``` - -## With Monitoring and Observability Tools - -Integrate heartbeat monitoring with your existing monitoring stack for unified observability. - -### Prometheus Integration - -```yaml -# prometheus.yml -scrape_configs: - - job_name: 'heartbeat-monitors' - static_configs: - - targets: ['checkly-exporter:8080'] - metrics_path: '/metrics' - scrape_interval: 30s -``` - -### Grafana Dashboard - -Create custom dashboards to visualize heartbeat monitor status alongside other metrics: - -```json -{ - "dashboard": { - "title": "Heartbeat Monitors Overview", - "panels": [ - { - "title": "Heartbeat Status", - "type": "stat", - "targets": [ - { - "expr": "heartbeat_monitor_status", - "legendFormat": "{{monitor_name}}" - } - ] - } - ] - } -} -``` - -## With Development Tools - -Integrate heartbeat monitoring into your development workflow and testing processes. - -### Local Development - -```bash -#!/bin/bash -# dev-heartbeat.sh -# Use during development to test heartbeat integration - -HEARTBEAT_URL="https://ping.checklyhq.com/your-dev-heartbeat-id" - -echo "Running development task..." -# Your development task here - -# Simulate successful completion -echo "Task completed successfully" -curl -m 5 --retry 3 $HEARTBEAT_URL -``` - -### Testing Framework Integration - -```python -# test_heartbeat_integration.py -import pytest -import requests -from unittest.mock import patch - -def test_backup_with_heartbeat(): - """Test that backup process pings heartbeat on success""" - with patch('requests.get') as mock_get: - # Run backup process - result = run_backup() - - # Verify backup succeeded - assert result.success - - # Verify heartbeat was pinged - mock_get.assert_called_once_with( - 'https://ping.checklyhq.com/your-backup-id', - timeout=5 - ) - -def test_backup_failure_no_heartbeat(): - """Test that heartbeat is not pinged on failure""" - with patch('requests.get') as mock_get: - # Simulate backup failure - with pytest.raises(Exception): - run_backup_with_failure() - - # Verify heartbeat was not pinged - mock_get.assert_not_called() -``` - -## Best Practices for Integration - -### Environment Management - -```bash -# Use environment variables for different environments -export HEARTBEAT_URL_PROD="https://ping.checklyhq.com/prod-backup-id" -export HEARTBEAT_URL_STAGING="https://ping.checklyhq.com/staging-backup-id" -export HEARTBEAT_URL_DEV="https://ping.checklyhq.com/dev-backup-id" - -# Use appropriate URL based on environment -HEARTBEAT_URL="${HEARTBEAT_URL_${ENVIRONMENT^^}}" -``` - -### Error Handling - -```python -import requests -import logging - -def ping_heartbeat(url, timeout=5, max_retries=3): - """Safely ping heartbeat with proper error handling""" - for attempt in range(max_retries): - try: - response = requests.get(url, timeout=timeout) - response.raise_for_status() - logging.info(f"Heartbeat pinged successfully") - return True - except requests.exceptions.RequestException as e: - logging.warning(f"Heartbeat ping attempt {attempt + 1} failed: {e}") - if attempt == max_retries - 1: - logging.error("All heartbeat ping attempts failed") - return False - return False -``` - -### Security Considerations - -```bash -# Use secrets management for heartbeat URLs -# Don't hardcode URLs in scripts or config files - -# Example with AWS Secrets Manager -HEARTBEAT_URL=$(aws secretsmanager get-secret-value \ - --secret-id heartbeat-urls \ - --query SecretString \ - --output text | jq -r .backup_heartbeat_url) -``` \ No newline at end of file diff --git a/detect/uptime-monitoring/locations.mdx b/detect/uptime-monitoring/locations.mdx deleted file mode 100644 index c35fa0e7..00000000 --- a/detect/uptime-monitoring/locations.mdx +++ /dev/null @@ -1,246 +0,0 @@ ---- -title: 'Monitoring Locations' -description: 'Choose optimal monitoring locations for global coverage and accurate performance insights across all monitor types.' -sidebarTitle: 'Locations' -canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/locations/' ---- - -Selecting the right monitoring locations ensures accurate uptime monitoring and provides insights into your service's global performance. This guide applies to URL, TCP, and Heartbeat monitors. - -## Types of Monitoring Locations - - - -Pre-configured monitoring points across 20+ locations worldwide - - - -Your own monitoring infrastructure for internal services - - - -## Available Global Locations - -### North America -- **US East** (N. Virginia) -- **US West** (Oregon) -- **US Central** (Dallas) -- **Canada Central** (Toronto) - -### Europe -- **EU West** (Ireland) -- **EU Central** (Frankfurt) -- **EU North** (Stockholm) -- **UK South** (London) - -### Asia Pacific -- **Asia Pacific Southeast** (Singapore) -- **Asia Pacific Northeast** (Tokyo) -- **Asia Pacific South** (Mumbai) -- **Asia Pacific East** (Sydney) - -### Other Regions -- **South America** (São Paulo) -- **Middle East** (Bahrain) -- **Africa** (Cape Town) - -## Location Selection Strategies - -### Match Your User Base -Select locations where your actual users are located to get realistic performance data and user experience insights. - -**Global Services:** -``` -Primary: US East, EU West, Asia Pacific Southeast -Secondary: US West, EU Central, Asia Pacific Northeast -``` - -**Regional Services:** -``` -North America: US East, US West, Canada Central -Europe: EU West, EU Central, UK South -Asia Pacific: AP Southeast, AP Northeast, AP South -``` - -### Coverage vs. Cost Balance - - - -2-3 strategic locations covering your primary markets - - - -5-7 locations providing global reach and redundancy - - - -**Recommended Starting Points:** -- **Startup/SMB**: 2-3 locations in primary regions -- **Growing Business**: 4-5 locations including international -- **Enterprise**: 6+ locations with private location supplements - -## Private Locations - -Private locations enable monitoring of internal services and compliance-restricted environments. - -### Use Cases -- **Internal APIs** and microservices -- **Database servers** and infrastructure components -- **Services behind firewalls** or VPNs -- **Compliance environments** with data sovereignty requirements -- **Development and staging** environments - -### Setup Requirements -1. Deploy Checkly agent in your infrastructure -2. Configure network access and firewall rules -3. Register location in Checkly dashboard -4. Assign monitors to private location - - -Private locations are available on Team and Enterprise plans. See [Private Locations documentation](/platform/private-locations/overview) for setup details. - - -## Location-Specific Considerations - -### Network Performance Factors -- **Geographic distance** from your servers -- **Internet infrastructure quality** in each region -- **CDN and edge server** distribution -- **Network routing paths** and peering relationships - -### Monitor Type Implications - -**URL Monitors:** -- Test from locations matching your web traffic -- Consider CDN performance variations -- Account for regional DNS resolution differences - -**TCP Monitors:** -- Focus on locations with direct network connectivity -- Consider firewall and security policies -- Test from regions accessing your infrastructure - -**Heartbeat Monitors:** -- Location affects ping delivery reliability -- Consider network connectivity from job execution environments -- Private locations ideal for internal scheduled tasks - -## Understanding Multi-Location Results - -### Status Aggregation -- Monitor shows **DOWN** if failing from any location -- **Partial outages** indicate regional issues -- **Location-specific failures** help isolate problems - -### Performance Analysis -Different response times across locations are normal and provide valuable insights: - -``` -Normal Patterns: -- Nearby locations: < 200ms -- Continental: 200-500ms -- Intercontinental: 500ms+ - -Investigation Triggers: -- Single location consistently 2x slower -- Sudden performance degradation in specific region -- New locations showing unexpected patterns -``` - -## Best Practices - -### Initial Setup -1. **Start with 2-3 strategic locations** in your primary markets -2. **Include one location near your infrastructure** for baseline performance -3. **Add international locations** based on user distribution -4. **Monitor and adjust** based on actual usage patterns - -### Ongoing Optimization -- **Review location performance** monthly -- **Adjust based on business expansion** into new regions -- **Consider seasonal traffic patterns** and user behavior -- **Remove underutilized locations** to optimize costs - -### Troubleshooting Location Issues - -**Single Location Problems:** -```yaml -Symptoms: One location failing while others pass -Diagnosis: - - Check regional network issues - - Verify CDN configuration - - Test manual connectivity from region -Resolution: May require infrastructure or routing changes -``` - -**Multiple Location Problems:** -```yaml -Symptoms: Failures across multiple regions -Diagnosis: - - Check overall service health - - Review recent deployments - - Verify DNS and CDN status -Resolution: Likely requires service-level fixes -``` - -## Scheduling Strategies by Location - -### Parallel Execution -All locations test simultaneously for fastest issue detection: -- **Pros**: Immediate global status, fastest alerting -- **Cons**: Higher server load, increased monitoring costs -- **Best for**: Critical services requiring immediate detection - -### Round-Robin Execution -Locations test in sequence to distribute load: -- **Pros**: Reduced server impact, lower costs -- **Cons**: Slower detection, sequential failure discovery -- **Best for**: Non-critical services, high-frequency monitoring - -## Advanced Location Configuration - -### Region-Based Alerting -Configure different alert behaviors by location: - -```yaml -Critical Regions (US East, EU West): - - Immediate alerts on any failure - - SMS escalation after 5 minutes - -Secondary Regions (Other locations): - - Email alerts after 2 consecutive failures - - Slack notification after 10 minutes -``` - -### Location-Specific Thresholds -Adjust expectations based on regional characteristics: - -```yaml -US East (Primary datacenter): - - Response time threshold: 500ms - - Immediate alerting - -Asia Pacific (Distant region): - - Response time threshold: 1500ms - - Allow for higher latency -``` - -## Next Steps - - - -Set up location-aware alerting and escalation rules - - - -Configure monitoring frequency and timing strategies - - - -Deploy monitoring agents in your own infrastructure - - - -Complete reference of all available monitoring locations - - diff --git a/detect/uptime-monitoring/scheduling.mdx b/detect/uptime-monitoring/scheduling.mdx deleted file mode 100644 index b01debf7..00000000 --- a/detect/uptime-monitoring/scheduling.mdx +++ /dev/null @@ -1,330 +0,0 @@ ---- -title: 'Scheduling and Frequency' -description: 'Configure optimal monitoring frequency and timing strategies for different types of uptime monitors.' -sidebarTitle: 'Scheduling' -canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/scheduling/' ---- - -Proper scheduling ensures effective monitoring while balancing detection speed, resource usage, and costs. This guide covers scheduling strategies for all monitor types. - -## Monitoring Frequency Options - -Different monitor types support various frequency settings: - -### Standard Frequencies -- **Every 10 seconds** - Ultra-high frequency for critical services -- **Every 30 seconds** - High frequency monitoring -- **Every minute** - Standard high-frequency monitoring -- **Every 5 minutes** - Balanced monitoring (most common) -- **Every 10 minutes** - Moderate frequency -- **Every 15 minutes** - Lower frequency monitoring -- **Every 30 minutes** - Infrequent monitoring -- **Every hour** - Low frequency monitoring -- **Custom intervals** - Up to 24 hours for specific needs - -## Frequency Selection Guidelines - -### By Service Criticality - -**Critical Production Services:** -```yaml -Frequency: Every 10 Seconds - 2 Minutes -Examples: Payment processing, user authentication, core APIs -Rationale: Immediate detection of issues affecting users -``` - -**Important Services:** -```yaml -Frequency: Every 5-10 minutes -Examples: Secondary APIs, admin interfaces, reporting tools -Rationale: Quick detection with reasonable resource usage -``` - -**Non-Critical Services:** -```yaml -Frequency: Every 15-30 minutes -Examples: Documentation sites, internal tools, dev environments -Rationale: Monitor availability without excessive overhead -``` - -### By Business Hours - -**Business-Critical Services:** -```yaml -Business Hours (9 AM - 6 PM): Every 1 minute -After Hours: Every 5 minutes -Weekends: Every 10 minutes -``` - -**Internal Services:** -```yaml -Business Hours: Every 5 minutes -After Hours: Every 15 minutes -Weekends: Every 30 minutes -``` - -## Scheduling Strategies - -### Parallel vs. Round-Robin Execution - - - -All locations run simultaneously for fastest detection - - - -Locations run sequentially to reduce server load - - - -**Parallel Execution:** -- **Use for**: Critical services requiring immediate alerts -- **Benefits**: Fastest issue detection, simultaneous global status -- **Considerations**: Higher server load, increased monitoring costs - -**Round-Robin Execution:** -- **Use for**: Cost-sensitive or non-critical monitoring -- **Benefits**: Distributed server load, lower monitoring costs -- **Considerations**: Slower issue detection, sequential location testing - -### Dynamic Scheduling - -Adjust frequency based on current conditions: - -**Deployment Monitoring:** -```yaml -During Deployment: Every 30 seconds -Post-Deployment (1 hour): Every 2 minutes -Normal Operations: Every 5 minutes -``` - -**Incident Response:** -```yaml -During Incident: Every 30 seconds -Recovery Period (2 hours): Every 1 minute -Stable State: Return to normal frequency -``` - -## Service-Specific Scheduling - -### Web Applications and APIs - -**E-commerce Sites:** -```yaml -Homepage: Every 1 minute (critical for revenue) -Product Pages: Every 5 minutes -Search API: Every 2 minutes -Checkout Flow: Every 30 seconds -``` - -**SaaS Applications:** -```yaml -Login Endpoint: Every 1 minute -Core Features: Every 5 minutes -Admin Interfaces: Every 15 minutes -Status Pages: Every 10 minutes -``` - -### Infrastructure Monitoring - -**Database Servers:** -```yaml -Primary Database: Every 2 minutes -Read Replicas: Every 5 minutes -Backup Systems: Every 15 minutes -``` - -**Load Balancers and Proxies:** -```yaml -Production Load Balancer: Every 1 minute -Staging Environment: Every 10 minutes -Development Proxies: Every 30 minutes -``` - -### Scheduled Jobs and Heartbeats - -**Daily Jobs:** -```yaml -Period: 24 hours -Grace Period: 30-60 minutes -Example: Nightly backups, daily reports -``` - -**Hourly Jobs:** -```yaml -Period: 1 hour -Grace Period: 10-15 minutes -Example: Data sync, cache refresh -``` - -**High-Frequency Jobs:** -```yaml -Period: 5-15 minutes -Grace Period: 2-5 minutes -Example: Real-time data processing, monitoring tasks -``` - -## Cost and Performance Optimization - -### Balancing Coverage and Cost - -**High-Value Optimization:** -```yaml -Strategy: Monitor critical paths frequently, everything else moderately -Implementation: - - User-facing services: Every 1-2 minutes - - Internal APIs: Every 5-10 minutes - - Dev/staging: Every 15-30 minutes -``` - -**Cost-Conscious Approach:** -```yaml -Strategy: Focus on essential monitoring with smart frequency -Implementation: - - Core services only: Every 5 minutes - - Reduce locations for non-critical services - - Use longer intervals during off-peak hours -``` - -### Resource Impact Considerations - -**Server Load Management:** -- Higher frequency = more requests to your servers -- Use round-robin scheduling to distribute load -- Consider rate limiting and caching implications -- Monitor your server metrics during frequency changes - -**Monitoring Budget:** -- More frequent checks = higher monitoring costs -- Balance detection speed with budget constraints -- Review and adjust frequencies based on actual value - -## Advanced Scheduling Patterns - -### Time-Based Scheduling - -**Business Hours Focus:** -```yaml -Business Hours (9 AM - 6 PM, Mon-Fri): - - Frequency: Every 1 minute - - All locations enabled - -Off Hours: - - Frequency: Every 10 minutes - - Reduced location set -``` - -**Seasonal Adjustments:** -```yaml -High Traffic Periods (Black Friday, holidays): - - Increase frequency by 50% - - Add additional monitoring locations - - Enable all alert channels - -Normal Periods: - - Standard frequency settings - - Regular location coverage -``` - -### Geographic Scheduling - -**Follow-the-Sun Monitoring:** -```yaml -Active Business Region: - - Higher frequency during local business hours - - All alerting channels active - -Other Regions: - - Reduced frequency during local off-hours - - Essential alerting only -``` - -### Failure-Adaptive Scheduling - -**Automatic Frequency Adjustment:** -```yaml -Healthy State: Normal frequency (every 5 minutes) -Warning State: Increased frequency (every 2 minutes) -Critical State: Maximum frequency (every 30 seconds) -Recovery: Gradual return to normal frequency -``` - -## Troubleshooting Scheduling Issues - -### Common Problems - -**Over-Monitoring:** -- **Symptoms**: High monitoring costs, server load issues -- **Solutions**: Reduce frequency for non-critical services, use round-robin scheduling - -**Under-Monitoring:** -- **Symptoms**: Late issue detection, missed outages -- **Solutions**: Increase frequency for critical paths, add more locations - -**Inconsistent Detection:** -- **Symptoms**: Intermittent alerts, unclear failure patterns -- **Solutions**: Adjust grace periods, review timeout settings - -### Performance Impact Analysis - -**Monitor Your Monitors:** -```yaml -Track Metrics: - - Server response time during monitoring - - Resource utilization patterns - - Alert frequency and false positives - - Mean time to detection vs. frequency -``` - -**Optimization Signals:** -```yaml -Increase Frequency When: - - High business impact of downtime - - Frequent but brief outages - - Service instability periods - -Decrease Frequency When: - - Stable service with rare issues - - High monitoring costs - - Server load concerns -``` - -## Best Practices - -### Initial Configuration -1. **Start conservative** with 5-10 minute intervals -2. **Monitor high-impact services more frequently** -3. **Adjust based on actual failure patterns** -4. **Consider business hours and user activity** - -### Ongoing Optimization -- **Review frequency effectiveness** quarterly -- **Adjust during high-risk periods** (deployments, traffic spikes) -- **Balance detection speed with cost constraints** -- **Use data-driven decisions** based on incident history - -### Documentation and Communication -- **Document scheduling rationale** for different services -- **Communicate frequency changes** to relevant teams -- **Track scheduling effectiveness** over time -- **Regular review with stakeholders** - -## Next Steps - - - -Configure alerting rules that work with your scheduling strategy - - - -Select optimal locations to complement your scheduling approach - - - -Configure retry strategies to work with your monitoring frequency - - - -Manage scheduling settings through code and automation - - diff --git a/detect/uptime-monitoring/tcp-monitors/use-cases.mdx b/detect/uptime-monitoring/tcp-monitors/use-cases.mdx deleted file mode 100644 index b6bf270b..00000000 --- a/detect/uptime-monitoring/tcp-monitors/use-cases.mdx +++ /dev/null @@ -1,383 +0,0 @@ ---- -title: 'TCP Monitor Use Cases' -description: 'Common use cases and real-world examples for TCP monitoring across different services and infrastructure components.' -sidebarTitle: 'Use Cases' -canonical: 'https://www.checklyhq.com/docs/detect/uptime-monitoring/tcp-monitors/use-cases/' -hidden: true ---- - -TCP monitors excel at validating network-level connectivity for various services and infrastructure components. Here are the most common and effective use cases for TCP monitoring. - -## Database Monitoring - -TCP monitors are perfect for checking database connectivity without exposing credentials or performing actual database operations. - -### MySQL/MariaDB -Monitor database server availability: - -```yaml -Host: db.production.com -Port: 3306 -Protocol: TCP -Timeout: 10s -Expected Response: (leave empty for basic connectivity) -``` - -**Benefits**: -- Verify database server is accepting connections -- Check before application deployments -- Monitor during maintenance windows -- Validate load balancer configuration - -### PostgreSQL -Monitor PostgreSQL instances: - -```yaml -Host: postgres.internal.com -Port: 5432 -Protocol: TCP -Connection String: (leave empty) -Expected Response: (leave empty) -``` - -### MongoDB -Check MongoDB replica sets: - -```yaml -Host: mongo-primary.cluster.com -Port: 27017 -Protocol: TCP -Timeout: 15s -``` - -### Redis Cache -Monitor Redis instances with ping validation: - -```yaml -Host: redis.cache.com -Port: 6379 -Protocol: TCP -Connection String: "PING\r\n" -Expected Response: "+PONG" -``` - -## Mail Server Monitoring - -Ensure mail services are accepting connections and responding correctly. - -### SMTP Server -Monitor outgoing mail servers: - -```yaml -Host: smtp.company.com -Port: 587 -Protocol: SSL/TLS -Expected Response: "220" -Timeout: 10s -``` - -**Use cases**: -- Validate SMTP server before sending bulk emails -- Monitor mail server during email campaigns -- Check SSL certificate expiration for secure SMTP -- Verify server response codes - -### IMAP Server -Monitor incoming mail servers: - -```yaml -Host: imap.company.com -Port: 993 -Protocol: SSL/TLS -Expected Response: "* OK" -``` - -### POP3 Server -Check POP3 mail access: - -```yaml -Host: pop3.company.com -Port: 995 -Protocol: SSL/TLS -Expected Response: "+OK" -``` - -## Custom TCP Services - -Monitor proprietary applications and custom network services. - -### Custom API Service -Monitor internal TCP-based APIs: - -```yaml -Host: api-internal.company.com -Port: 8080 -Protocol: TCP -Connection String: "HEALTH\n" -Expected Response: "OK" -``` - -### Microservice Health Checks -Monitor service-to-service communication: - -```yaml -Host: user-service.internal -Port: 9090 -Protocol: TCP -Connection String: "STATUS\n" -Expected Response: "READY" -``` - -### Game Servers -Monitor multiplayer game servers: - -```yaml -Host: game-server-1.company.com -Port: 7777 -Protocol: TCP -Connection String: "PING\n" -Expected Response: "PONG" -``` - -## Infrastructure Services - -Monitor critical infrastructure components that don't expose HTTP endpoints. - -### SSH Servers -Verify SSH server availability: - -```yaml -Host: bastion.company.com -Port: 22 -Protocol: TCP -Expected Response: "SSH-2.0" -``` - -**Benefits**: -- Ensure remote access is available -- Monitor jump servers and bastion hosts -- Check before scheduled maintenance -- Verify firewall configurations - -### FTP/SFTP Servers -Monitor file transfer services: - -```yaml -# FTP Server -Host: ftp.company.com -Port: 21 -Protocol: TCP -Expected Response: "220" - -# SFTP Server -Host: sftp.company.com -Port: 22 -Protocol: TCP -Expected Response: "SSH-2.0" -``` - -### VPN Endpoints -Monitor VPN server availability: - -```yaml -Host: vpn.company.com -Port: 1194 -Protocol: TCP -Timeout: 15s -``` - -## Load Balancer and Proxy Monitoring - -Ensure traffic routing infrastructure is functioning correctly. - -### HAProxy Health Checks -Monitor load balancer status: - -```yaml -Host: lb-primary.company.com -Port: 80 -Protocol: TCP -Connection String: "GET /health HTTP/1.1\r\nHost: lb-primary.company.com\r\n\r\n" -Expected Response: "200 OK" -``` - -### NGINX Proxy -Check reverse proxy connectivity: - -```yaml -Host: proxy.company.com -Port: 8080 -Protocol: TCP -``` - -### Cloud Load Balancers -Monitor AWS/Azure/GCP load balancers: - -```yaml -Host: lb-abc123.us-west-2.elb.amazonaws.com -Port: 443 -Protocol: SSL/TLS -``` - -## Message Queue Systems - -Monitor message broker connectivity and health. - -### RabbitMQ -Monitor RabbitMQ message broker: - -```yaml -Host: rabbitmq.company.com -Port: 5672 -Protocol: TCP -``` - -For management interface: -```yaml -Host: rabbitmq.company.com -Port: 15672 -Protocol: TCP -``` - -### Apache Kafka -Monitor Kafka broker availability: - -```yaml -Host: kafka-broker-1.company.com -Port: 9092 -Protocol: TCP -``` - -### Apache ActiveMQ -Monitor ActiveMQ message broker: - -```yaml -Host: activemq.company.com -Port: 61616 -Protocol: TCP -``` - -## Container and Orchestration Services - -Monitor containerized applications and orchestration platforms. - -### Docker Registry -Monitor private Docker registries: - -```yaml -Host: registry.company.com -Port: 5000 -Protocol: TCP -``` - -### Kubernetes API Server -Monitor Kubernetes cluster access: - -```yaml -Host: k8s-master.company.com -Port: 6443 -Protocol: SSL/TLS -``` - -### Consul Service Discovery -Monitor HashiCorp Consul: - -```yaml -Host: consul.company.com -Port: 8500 -Protocol: TCP -``` - -## Monitoring Strategies by Environment - -### Production Environment -- **Critical services**: Monitor every 1-2 minutes -- **Supporting services**: Monitor every 5 minutes -- **Multiple locations**: Use 5+ global monitoring points -- **Alerting**: Immediate notifications for failures - -### Staging Environment -- **Deployment validation**: Monitor during deployments -- **Pre-production testing**: Verify service connectivity -- **Integration testing**: Monitor service dependencies -- **Frequency**: Every 5-10 minutes - -### Development Environment -- **Service availability**: Basic connectivity checks -- **Development workflow**: Monitor during active development -- **Frequency**: Every 15-30 minutes -- **Alerting**: Email notifications only - -## Industry-Specific Use Cases - -### E-commerce -- **Payment processors**: Monitor payment gateway connections -- **Inventory systems**: Check database connectivity -- **Email services**: Monitor SMTP for order confirmations -- **CDN services**: Verify content delivery networks - -### Financial Services -- **Trading systems**: Monitor market data feeds -- **Core banking**: Check database connections -- **Security services**: Monitor authentication servers -- **Compliance systems**: Verify audit log services - -### Healthcare -- **EMR systems**: Monitor electronic medical records -- **DICOM services**: Check medical imaging systems -- **HL7 interfaces**: Monitor healthcare data exchange -- **Backup systems**: Verify data protection services - -### SaaS Applications -- **Multi-tenant databases**: Monitor tenant isolation -- **Background services**: Check job processing systems -- **API gateways**: Monitor service mesh connectivity -- **Cache layers**: Verify distributed cache health - -## Integration with Monitoring Strategy - -### Combine with HTTP Checks -Use TCP monitors alongside HTTP monitors for complete coverage: - -```yaml -# TCP monitor for database connectivity -TCP Monitor: db.company.com:3306 - -# HTTP monitor for application health -HTTP Monitor: https://app.company.com/health -``` - -### Cascade Monitoring -Set up dependency-aware monitoring: - -1. **Infrastructure Layer**: TCP monitors for databases, message queues -2. **Application Layer**: HTTP monitors for APIs and web services -3. **User Experience**: Browser checks for complete user journeys - -### Alert Correlation -Configure alerts to understand service dependencies: - -- Database TCP failure → Application HTTP failures -- Message queue TCP failure → Background job delays -- Load balancer TCP failure → All service unavailability - - -TCP monitors provide network-level validation but cannot detect application-logic issues. Combine them with HTTP monitors and synthetic checks for comprehensive coverage. - - -## Next Steps - - - - -Get started with step-by-step setup instructions - - - -Explore HTTP-based monitoring for web services - - - -Set up effective alerting for your TCP monitors - - diff --git a/docs.json b/docs.json index 9d236c32..d9488e7a 100644 --- a/docs.json +++ b/docs.json @@ -1475,6 +1475,66 @@ } }, "redirects": [ + { + "source": "/detect/synthetic-monitoring/api-checks/examples", + "destination": "/detect/synthetic-monitoring/api-checks/setup-and-teardown" + }, + { + "source": "/detect/synthetic-monitoring/browser-checks/best-practices", + "destination": "/detect/synthetic-monitoring/browser-checks/overview" + }, + { + "source": "/detect/synthetic-monitoring/api-checks/best-practices", + "destination": "/detect/synthetic-monitoring/api-checks/overview" + }, + { + "source": "/detect/uptime-monitoring/heartbeat-monitors/iac-configuration", + "destination": "/constructs/heartbeat-monitor" + }, + { + "source": "/detect/uptime-monitoring/heartbeat-monitors/cli-configuration", + "destination": "/constructs/heartbeat-monitor" + }, + { + "source": "/detect/uptime-monitoring/heartbeat-monitors/cron-configuration", + "destination": "/detect/uptime-monitoring/heartbeat-monitors/examples" + }, + { + "source": "/detect/uptime-monitoring/heartbeat-monitors/ci-cd-configuration", + "destination": "/detect/uptime-monitoring/heartbeat-monitors/examples" + }, + { + "source": "/detect/uptime-monitoring/heartbeat-monitors/other", + "destination": "/detect/uptime-monitoring/heartbeat-monitors/examples" + }, + { + "source": "/detect/uptime-monitoring/alerting", + "destination": "/communicate/alerts/overview" + }, + { + "source": "/detect/uptime-monitoring/locations", + "destination": "/concepts/locations" + }, + { + "source": "/detect/uptime-monitoring/scheduling", + "destination": "/concepts/scheduling" + }, + { + "source": "/detect/uptime-monitoring/cli-configuration", + "destination": "/detect/uptime-monitoring/overview" + }, + { + "source": "/detect/uptime-monitoring/tcp-monitors/use-cases", + "destination": "/detect/uptime-monitoring/tcp-monitors/overview" + }, + { + "source": "/concepts/monitors", + "destination": "/detect/uptime-monitoring/overview" + }, + { + "source": "/communicate/alerts/best-practices", + "destination": "/communicate/alerts/overview" + }, { "source": "/guides/auto-waiting-methods", "destination": "/learn/playwright/waits-and-timeouts" diff --git a/integrations/ci-cd/vercel/deployment-protection.mdx b/integrations/ci-cd/vercel/deployment-protection.mdx index e628e92e..2a83bda7 100644 --- a/integrations/ci-cd/vercel/deployment-protection.mdx +++ b/integrations/ci-cd/vercel/deployment-protection.mdx @@ -187,7 +187,7 @@ explore bypassing 2FA using the `otpauth` library. [Check our blog post for more Vercel's [Password Protection](https://vercel.com/docs/concepts/deployments/deployment-protection#password-protection) is a paid addon that allows you to set a dedicated password for your deployments and specifically bypass protection for E2E tests / automation. You can accomplish this using the resources referenced in the docs for [browser checks](/detect/synthetic-monitoring/browser-checks/examples#username--password-login) -or [API requests](https://www.checklyhq.com/docs/detect/synthetic-monitoring/api-checks/examples#dismiss-password-protection-prompt-on-vercel-deployment). +or [API checks](/detect/synthetic-monitoring/api-checks/setup-and-teardown). - [IP Allowlisting](https://vercel.com/docs/concepts/deployments/deployment-protection#ip-allowlisting)