Private Locations enable monitoring scenarios that aren’t possible with public monitoring locations. Explore these common use cases and implementation patterns.

​
Development Environment Monitoring

Monitor staging and development environments that aren’t accessible from the internet: 
# Development environment agent
docker run \
  -e API_KEY="pl_dev_environment_key" \
  -e LOG_LEVEL="DEBUG" \
  --name checkly-agent-dev \
  -d checkly/agent:latest
Common monitoring targets:
  • Internal development APIs
  • Test databases and staging applications
  • CI/CD pipeline endpoints
  • Internal documentation sites
  • Development tools and dashboards
Benefits:
  • Catch issues before production deployment
  • Validate staging environment health
  • Monitor development workflow tools
  • Ensure internal services are available

​
Database and Backend Services

Monitor internal database health and backend services: 
// Monitor database connection pool
new ApiCheck('database-pool-check', {
  name: 'Database Pool Health',
  request: {
    method: 'GET',
    url: 'http://db-monitor.internal:9090/pool-status'
  },
  privateLocations: ['datacenter-primary'],
  assertions: [
    { source: 'JSON_BODY', property: '$.activeConnections', comparison: 'LESS_THAN', target: 80 },
    { source: 'JSON_BODY', property: '$.poolUtilization', comparison: 'LESS_THAN', target: 0.9 }
  ]
})
Monitoring targets:
  • Database connection pools
  • Internal health check endpoints
  • Backend service APIs
  • Message queue systems
  • Cache servers and Redis instances
Key metrics to monitor:
  • Connection pool utilization
  • Query response times
  • Service availability
  • Error rates and timeouts

​
Microservices Architecture

Monitor service-to-service communication in complex architectures: 
// Check internal service mesh health
new ApiCheck('service-mesh-check', {
  name: 'Service Mesh Health',
  request: {
    method: 'GET',
    url: 'http://istio-proxy.istio-system:15000/stats/prometheus',
    headers: { 'Accept': 'text/plain' }
  },
  privateLocations: ['kubernetes-cluster'],
  assertions: [
    { source: 'RESPONSE_TIME', comparison: 'LESS_THAN', target: 1000 }
  ]
})
Architecture patterns:
  • Service mesh health monitoring
  • Internal API gateway checks
  • Load balancer health validation
  • Circuit breaker status monitoring
  • Service discovery endpoints
Deployment considerations:
  • Deploy agents in each Kubernetes cluster
  • Monitor cross-cluster communication
  • Validate service mesh policies
  • Check internal load balancer health

​
Compliance and Governance

Meet regulatory requirements with local monitoring: 
# EU-specific private location for GDPR compliance
docker run \
  -e API_KEY="pl_eu_compliance_key" \
  -e LOG_LEVEL="INFO" \
  --label "compliance=gdpr" \
  --label "region=eu-west" \
  -d checkly/agent:latest
Compliance scenarios:
  • GDPR: EU data residency requirements
  • HIPAA: Healthcare data protection
  • SOX: Financial data governance
  • FedRAMP: Government cloud compliance
  • Industry-specific: Banking, insurance, etc.
Implementation strategies:
  • Deploy agents in compliant regions
  • Use dedicated networks for sensitive data
  • Implement audit logging for monitoring activities
  • Ensure data doesn’t cross geographic boundaries

​
E-commerce and Internal Applications

Monitor internal business applications and e-commerce systems: 
// Monitor internal order processing system
new BrowserCheck('order-processing-check', {
  name: 'Order Processing Flow',
  code: {
    entrypoint: './order-processing.spec.ts'
  },
  privateLocations: ['internal-network'],
  maxResponseTime: 30000
})
Application types:
  • Internal order management systems
  • Inventory management platforms
  • Customer relationship management (CRM)
  • Enterprise resource planning (ERP)
  • Internal dashboards and reporting tools
Testing scenarios:
  • End-to-end order processing flows
  • Inventory update processes
  • User authentication and authorization
  • Data synchronization between systems
  • Report generation and export

​
Network Infrastructure Monitoring

Monitor internal network components and infrastructure: 
// Monitor internal load balancer health
new ApiCheck('load-balancer-health', {
  name: 'Internal Load Balancer Status',
  request: {
    method: 'GET',
    url: 'http://lb-internal.company.local/health'
  },
  privateLocations: ['datacenter-east'],
  assertions: [
    { source: 'STATUS_CODE', comparison: 'EQUALS', target: 200 },
    { source: 'JSON_BODY', property: '$.healthyBackends', comparison: 'GREATER_THAN', target: 0 }
  ]
})
Infrastructure components:
  • Internal load balancers
  • Reverse proxies and API gateways
  • Network storage systems
  • Backup and disaster recovery systems
  • Monitoring and logging infrastructure
Monitoring focus:
  • Component availability and health
  • Performance metrics and response times
  • Configuration validation
  • Security endpoint testing

​
Multi-Environment Monitoring

Deploy agents across multiple environments for comprehensive monitoring: 
# Production environment
docker run \
  -e API_KEY="pl_prod_key" \
  -e ENVIRONMENT="production" \
  --name checkly-agent-prod \
  -d checkly/agent:latest

# Staging environment  
docker run \
  -e API_KEY="pl_staging_key" \
  -e ENVIRONMENT="staging" \
  --name checkly-agent-staging \
  -d checkly/agent:latest

# Development environment
docker run \
  -e API_KEY="pl_dev_key" \
  -e ENVIRONMENT="development" \
  --name checkly-agent-dev \
  -d checkly/agent:latest
Environment strategy:
  • Separate agents per environment
  • Environment-specific check configurations
  • Different alerting thresholds
  • Isolated monitoring data

​
High Availability and Disaster Recovery

Implement redundant monitoring for critical systems: 
// Multi-location monitoring for critical service
new ApiCheck('critical-service-check', {
  name: 'Critical Service Health',
  request: {
    method: 'GET',
    url: 'http://critical-service.internal/health'
  },
  privateLocations: ['datacenter-primary', 'datacenter-secondary'],
  maxResponseTime: 5000,
  retryCount: 3
})
Redundancy patterns:
  • Multiple agents per location
  • Cross-datacenter monitoring
  • Failover monitoring strategies
  • Geographic redundancy for compliance
Implementation considerations:
  • Load distribution across agents
  • Failover detection and alerting
  • Data consistency across locations
  • Recovery time objectives (RTO)

​
Best Practices

Use consistent naming for your Private Locations:
  • Include environment (prod, staging, dev)
  • Specify geographic region or datacenter
  • Add purpose or team identifier
  • Examples: prod-us-east-1, staging-eu-west, dev-team-a
Plan your agent deployment based on workload:
  • Estimate concurrent checks per agent
  • Consider memory requirements for browser checks
  • Plan for peak load scenarios
  • Monitor agent resource utilization
Secure your Private Location deployment:
  • Use secrets management for API keys
  • Implement network segmentation
  • Monitor agent access logs
  • Regular security updates and patches
Design a comprehensive monitoring approach:
  • Start with critical services
  • Gradually expand coverage
  • Implement alerting hierarchies
  • Regular review and optimization

​
Next Steps

Explore these related topics to enhance your Private Location deployment:

Agent Configuration

Learn advanced configuration options and environment variables

Kubernetes Deployment

Deploy at scale with Kubernetes orchestration

CLI Integration

Integrate with monitoring-as-code workflows

Scaling Guide

Plan for growth and implement redundancy