diff --git a/docs.json b/docs.json
index 992dac77..b482aeb8 100644
--- a/docs.json
+++ b/docs.json
@@ -83,9 +83,6 @@
"group": "Private Locations",
"pages": [
"platform/private-locations/overview",
- "platform/private-locations/quick-start",
- "platform/private-locations/use-cases",
- "platform/private-locations/cli-integration",
"platform/private-locations/agent-configuration",
"platform/private-locations/dev-agent",
"platform/private-locations/kubernetes-deployment",
diff --git a/platform/private-locations/agent-configuration.mdx b/platform/private-locations/agent-configuration.mdx
index 4d66e594..0ca2d2a3 100644
--- a/platform/private-locations/agent-configuration.mdx
+++ b/platform/private-locations/agent-configuration.mdx
@@ -2,7 +2,7 @@
title: 'Agent Configuration'
---
-The Checkly Agent is a container that you need to deploy to run a Private Location in Checkly. The agent needs to be deployed on your infrastructure and executes checks on behalf of the Checkly application. For installation details, [check the getting started guide](/platform/private-locations/quick-start).
+The Checkly Agent is a container that you need to deploy to run a Private Location in Checkly. The agent needs to be deployed on your infrastructure and executes checks on behalf of the Checkly application. For installation details, [check the getting started guide](/platform/private-locations/overview).
The Checkly Agent has several environment variables that can be configured:
diff --git a/platform/private-locations/cli-integration.mdx b/platform/private-locations/cli-integration.mdx
deleted file mode 100644
index a8c9dbcf..00000000
--- a/platform/private-locations/cli-integration.mdx
+++ /dev/null
@@ -1,345 +0,0 @@
----
-title: 'Private Locations CLI Integration'
-description: 'Integrate Private Locations with Checkly CLI and monitoring-as-code workflows. Define Private Locations in your TypeScript and JavaScript projects.'
-sidebarTitle: 'CLI Integration'
----
-
-
-
-# Integration with Checkly CLI
-
-Define Private Locations in your monitoring-as-code workflow using the Checkly CLI. This enables version-controlled, repeatable deployments of your monitoring infrastructure.
-
-## Basic Configuration
-
-
-
-```typescript
-import { ApiCheck, BrowserCheck } from 'checkly/constructs'
-
-// API check using private location
-new ApiCheck('internal-api-check', {
- name: 'Internal API Health',
- request: {
- method: 'GET',
- url: 'http://internal-api.company.local/health'
- },
- privateLocations: ['company-datacenter-east'],
- maxResponseTime: 5000
-})
-
-// Browser check using private location
-new BrowserCheck('internal-app-check', {
- name: 'Internal App Login Flow',
- code: {
- entrypoint: './internal-app.spec.ts'
- },
- privateLocations: ['company-datacenter-east']
-})
-```
-
-
-```javascript
-const { ApiCheck, BrowserCheck } = require('checkly/constructs')
-
-// API check for internal service
-new ApiCheck('database-health-check', {
- name: 'Database Connection Health',
- request: {
- method: 'GET',
- url: 'http://db-proxy.internal:8080/health'
- },
- privateLocations: ['internal-network'],
- assertions: [
- { source: 'STATUS_CODE', comparison: 'EQUALS', target: 200 }
- ]
-})
-```
-
-
-
-## Advanced Configuration
-
-### Multiple Private Locations
-
-Configure checks to run from multiple Private Locations for redundancy:
-
-```typescript
-new ApiCheck('critical-service-check', {
- name: 'Critical Service Health',
- request: {
- method: 'GET',
- url: 'http://critical-service.internal/health'
- },
- privateLocations: ['datacenter-primary', 'datacenter-secondary'],
- maxResponseTime: 3000,
- retryCount: 2
-})
-```
-
-### Environment-Specific Configuration
-
-Use environment variables to configure Private Locations dynamically:
-
-```typescript
-// checkly.config.ts
-import { defineConfig } from 'checkly/constructs'
-
-export default defineConfig({
- projectName: 'Internal Monitoring',
- logicalId: 'internal-monitoring',
- checks: {
- locations: ['us-east-1', 'eu-west-1'],
- privateLocations: process.env.PRIVATE_LOCATIONS?.split(',') || [],
- tags: ['internal', process.env.ENVIRONMENT || 'development']
- }
-})
-```
-
-### Conditional Private Location Usage
-
-Use conditional logic to determine Private Location usage:
-
-```typescript
-const usePrivateLocations = process.env.USE_PRIVATE_LOCATIONS === 'true'
-const privateLocationNames = usePrivateLocations ? ['internal-network'] : []
-
-new ApiCheck('service-health-check', {
- name: 'Service Health Check',
- request: {
- method: 'GET',
- url: process.env.SERVICE_URL || 'http://localhost:8080/health'
- },
- privateLocations: privateLocationNames,
- tags: usePrivateLocations ? ['private-location'] : ['public-location']
-})
-```
-
-## Deployment Workflows
-
-### CI/CD Integration
-
-Integrate Private Location checks into your CI/CD pipeline:
-
-```yaml
-# .github/workflows/deploy-checks.yml
-name: Deploy Monitoring Checks
-
-on:
- push:
- branches: [main]
- pull_request:
- branches: [main]
-
-jobs:
- deploy-checks:
- runs-on: ubuntu-latest
- steps:
- - uses: actions/checkout@v3
-
- - name: Setup Node.js
- uses: actions/setup-node@v3
- with:
- node-version: '18'
-
- - name: Install dependencies
- run: npm install
-
- - name: Deploy to Checkly
- env:
- CHECKLY_API_KEY: ${{ secrets.CHECKLY_API_KEY }}
- PRIVATE_LOCATIONS: ${{ secrets.PRIVATE_LOCATIONS }}
- ENVIRONMENT: production
- run: npx checkly deploy
-```
-
-### Environment-Specific Deployments
-
-Deploy different configurations for different environments:
-
-```bash
-#!/bin/bash
-# deploy-monitoring.sh
-
-ENVIRONMENT=$1
-PRIVATE_LOCATIONS=""
-
-case $ENVIRONMENT in
- "production")
- PRIVATE_LOCATIONS="prod-datacenter-east,prod-datacenter-west"
- ;;
- "staging")
- PRIVATE_LOCATIONS="staging-datacenter"
- ;;
- "development")
- PRIVATE_LOCATIONS="dev-network"
- ;;
- *)
- echo "Unknown environment: $ENVIRONMENT"
- exit 1
- ;;
-esac
-
-export PRIVATE_LOCATIONS
-export ENVIRONMENT
-
-npx checkly deploy
-```
-
-## Project Structure
-
-Organize your monitoring-as-code project for Private Locations:
-
-```
-monitoring-project/
-├── checkly.config.ts
-├── package.json
-├── checks/
-│ ├── api/
-│ │ ├── internal-services.ts
-│ │ └── database-health.ts
-│ ├── browser/
-│ │ ├── internal-apps.ts
-│ │ └── admin-dashboards.ts
-│ └── shared/
-│ ├── assertions.ts
-│ └── helpers.ts
-├── environments/
-│ ├── production.ts
-│ ├── staging.ts
-│ └── development.ts
-└── scripts/
- ├── deploy.sh
- └── validate.sh
-```
-
-### Configuration Files
-
-**checkly.config.ts:**
-```typescript
-import { defineConfig } from 'checkly/constructs'
-import { productionConfig } from './environments/production'
-import { stagingConfig } from './environments/staging'
-
-const config = process.env.ENVIRONMENT === 'production'
- ? productionConfig
- : stagingConfig
-
-export default defineConfig(config)
-```
-
-**environments/production.ts:**
-```typescript
-import { ChecklyConfig } from 'checkly/constructs'
-
-export const productionConfig: ChecklyConfig = {
- projectName: 'Production Internal Monitoring',
- logicalId: 'prod-internal-monitoring',
- checks: {
- privateLocations: ['prod-datacenter-east', 'prod-datacenter-west'],
- tags: ['production', 'internal'],
- runtimeId: '2023.09'
- },
- cli: {
- runParallel: true,
- runLocation: 'us-east-1'
- }
-}
-```
-
-## Best Practices
-
-
-
-- Store Private Location configurations in version control
-- Use environment-specific configuration files
-- Document Private Location dependencies
-- Include deployment scripts in your repository
-
-
-
-- Use environment variables for sensitive configuration
-- Never commit API keys or secrets
-- Implement least-privilege access for deployment
-- Use separate Private Locations for different environments
-
-
-
-- Test Private Location configurations locally
-- Validate check configurations before deployment
-- Use staging environments for testing
-- Implement rollback procedures
-
-
-
-- Monitor your monitoring deployment
-- Track Private Location agent health
-- Alert on deployment failures
-- Regular review of check configurations
-
-
-
-## Troubleshooting
-
-### Common Issues
-
-**Private Location Not Found:**
-```bash
-Error: Private location 'internal-network' not found
-```
-
-**Solution:** Ensure the Private Location exists in your Checkly account and the name matches exactly.
-
-**Agent Not Connected:**
-```bash
-Warning: No agents connected to private location 'internal-network'
-```
-
-**Solution:** Verify that agents are running and connected to the Private Location.
-
-**Deployment Failures:**
-```bash
-Error: Failed to deploy checks to private location
-```
-
-**Solution:** Check agent connectivity, API key validity, and network access.
-
-### Debugging Commands
-
-```bash
-# Validate configuration
-npx checkly validate
-
-# Test check execution
-npx checkly test --location internal-network
-
-# Check agent status
-npx checkly whoami
-
-# Deploy with verbose logging
-npx checkly deploy --verbose
-```
-
-## Next Steps
-
-
-
-Learn advanced agent configuration options
-
-
-
-Explore real-world deployment patterns
-
-
-
-Deploy at scale with Kubernetes
-
-
-
-Plan for growth and redundancy
-
-
-
-
-Start with a simple configuration and gradually add complexity as you become familiar with Private Location integration patterns.
-
diff --git a/platform/private-locations/overview.mdx b/platform/private-locations/overview.mdx
index 73b74ad2..63fc145f 100644
--- a/platform/private-locations/overview.mdx
+++ b/platform/private-locations/overview.mdx
@@ -1,5 +1,5 @@
---
-title: 'Private Locations Overview'
+title: 'Getting started with Private Locations'
description: 'Monitor internal systems and test from custom locations using Checkly Private Locations. Run checks from within your own infrastructure with the lightweight Checkly Agent.'
sidebarTitle: 'Overview'
---
@@ -9,110 +9,111 @@ sidebarTitle: 'Overview'
-**Owner** or **Admin** permissions are required to create, edit, and delete Private Locations. All other roles can view Private Locations and assign checks to them.
+**Owner** or **Admin** permissions are required to create, edit, and delete Private Locations.
-Private Locations enable you to run Checkly monitoring from within your own infrastructure. By deploying a lightweight Checkly Agent, you can monitor internal systems, test from specific geographic locations, and maintain complete control over your monitoring environment.
+A Private Location is a monitoring location that you manage by simply deploying a lightweight Checkly Agent.
-A Private Location is a custom monitoring location that you control by deploying Checkly Agent containers in your infrastructure. These agents connect securely to Checkly and execute your checks from within your network environment.
+Running a check from a Private Location allows you to:
-
+- **Monitor internal systems**: Test the performance and reliability of applications and APIs that are only accessible from within your network (e.g., development environments, intranet tools)
+- **Test from anywhere**: Test the performance and reliability of applications and APIs from different parts of the world. Install your Checkly Agent(s) for location-based performance insights, that we don't cover with our [Global Locations](/concepts/locations)
-## How Private Locations Work
+Configure your checks to use your Private Location and that's it. As long as you have at least one operational Checkly Agent, checks will run in your Private Location. [Adding more agents](/platform/private-locations/scaling-redundancy) will distribute the load and improve resilience automatically.
-The process is straightforward and secure:
+## Requirements
-1. **Create a Private Location** in your Checkly account
-2. **Deploy Checkly Agents** using the provided API key
-3. **Configure your checks** to use your Private Location
-4. **Monitor results** just like any other Checkly check
+Here are the requirements before you get started:
-## Key Benefits
+- A container runtime (we test using Docker, but other runtimes should work)
+- Outbound internet access for the Agent to https://agent.checklyhq.com (proxy configuration is supported)
+- Access to your API or browser-based applications and services from the Private Location network
+- Owner or Admin permissions (required to create, edit, and delete Private Locations)
-### Network-Level Access
+## Configuring a Private Location
-Private Locations run inside your network perimeter, giving you access to:
-- Internal APIs and services not exposed to the internet
-- Development and staging environments
-- Database connections and internal tools
-- Services behind VPNs or private networks
+1. Navigate to the [Private Locations page](https://app.checklyhq.com/private-locations) and click "New private location"
-### Geographic Flexibility
+ 
-Deploy agents anywhere to get location-specific insights:
-- Test from regions not covered by Checkly's global network
-- Monitor from your actual data center locations
-- Validate performance from specific customer regions
-- Meet regulatory requirements for local testing
+2. Provide a name and icon for the new private location. The ID is automatically generated ID for API access. Click create.
-### Security and Compliance
+ 
-Maintain complete control over your monitoring environment:
-- Keep sensitive data within your network
-- Meet compliance requirements for data residency
-- Maintain audit trails within your infrastructure
-- Use your existing security policies and controls
+3. You will receive an API key for the new location. Copy this key and keep it safe as you will need it to add agents to the location, and you won’t be able to see it again.
-### Scalable and Resilient
+ 
-Design for production workloads:
-- Horizontal scaling with multiple agents
-- Automatic load distribution across agents
-- Graceful handling of agent failures
-- Zero-downtime updates and maintenance
+4. Start the Checkly agent by running the following command in a terminal, making sure to replace the `API_KEY` with the key you just received.
+[See more configuration options.](/platform/private-locations/agent-configuration)
+```bash
+docker run -e API_KEY="pl_...." -d checkly/agent:latest
+```
-## Requirements
-Before setting up Private Locations, ensure you have:
+5. Refresh the Private Locations page in the Checkly app and you will see a count of the number of running agents.
+
+ 
+
+6. Create a new check as you normally would in Checkly. You will now see your new private location in the list of available locations. Select it and deselect any other locations.
+
+ 
+
+
+## Using Private Locations with the CLI
+
+With the [Checkly CLI](/cli/overview), you can configure any check to run on a Private Location by adding the slug name to the `privateLocations` array. For example, with an [ApiCheck construct](/constructs/api-check):
+
+```ts {title="api.check.ts"}
+import { ApiCheck } from 'checkly/constructs'
+
+new ApiCheck('hello-api-1', {
+ name: 'Hello API',
+ activated: true,
+ maxResponseTime: 10000,
+ degradedResponseTime: 5000,
+ privateLocations: ['blairs-private-network'],
+ request: {
+ method: 'GET',
+ url: ' https://checklyhq.com.org/',
+ }
+})
+```
+
+## Unavailable Private Locations
-
+If a private location has had no Checkly agents connected for more than 10 minutes, it will be flagged as unavailable. Checkly will email account owners and admins that the location has become unavailable.
-
-- Container runtime (Docker, Podman, or similar)
-- Outbound HTTPS access to `agent.checklyhq.com`
-- Network access to your target applications
-- Sufficient CPU and memory resources
-
+While a location is unavailable, no checks will be scheduled to run on it. When a location becomes available, check scheduling and execution will resume automatically.
-
-- Checkly account with Owner or Admin role
-- Ability to deploy containers in your infrastructure
-- Network configuration permissions
-- Optional: HTTP proxy configuration capability
-
+## Using Playwright Check Suites in Private Locations
-
-
-**Memory Guidelines:**
-- API checks: ~150MB per concurrent check
-- Browser checks: ~1.5GB per concurrent check
-- Minimum recommended: 2 CPU cores, 4GB RAM for mixed workloads
-
-
+We recommend to update the Checkly agent regularly.
-
+* [Playwright Check Suites](/detect/synthetic-monitoring/playwright-checks/overview) are available in private locations since Checkly Agent `6.0.3`.
-## Agent Lifecycle Management
+Please use a minimum container size of 2 CPU cores and 4 GB of RAM when running Playwright Check Suites.
-### Agent Status Monitoring
+## Next Steps
-Checkly monitors agent connectivity and health:
+Once your first agent is running, explore these topics to start using Private Locations in production:
-- **Active**: Agent is connected and processing checks
-- **Unavailable**: No agents connected for 10+ minutes
-- **Degraded**: Some agents disconnected, reduced capacity
+
+
+Detailed agent configuration options, updating your agent, runtime support, and more.
+
-When a Private Location becomes unavailable, Checkly automatically:
-- Stops scheduling new checks for that location
-- Emails account owners and admins
-- Resumes scheduling when agents reconnect
+
+Run production-grade agent deployments on a container orchestrator like Kubernetes.
+
-### Load Distribution
+
+How to calculate the number of agents and amount of resources needed.
+
-Multiple agents in the same Private Location automatically:
-- Share check execution load
-- Provide redundancy and high availability
-- Handle graceful failover during agent restarts
-- Requeue checks from failed agents (300-second timeout)
+
+Use the dev agent for npm packages that require compilation.
+
+
diff --git a/platform/private-locations/quick-start.mdx b/platform/private-locations/quick-start.mdx
deleted file mode 100644
index 608252c0..00000000
--- a/platform/private-locations/quick-start.mdx
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: 'Private Locations Quick Start'
-description: 'Get up and running with Private Locations in minutes. Follow this step-by-step guide to deploy your first Checkly Agent.'
-sidebarTitle: 'Quick Start'
----
-
-
-# Quick Start Guide
-
-Follow this step-by-step guide to set up your first Private Location and start monitoring internal systems.
-
-## Prerequisites
-
-Before you begin, ensure you have:
-
-- **Checkly Account**: Owner or Admin permissions
-- **Infrastructure**: Container runtime (Docker, Podman, or similar)
-- **Network Access**: Outbound HTTPS to `agent.checklyhq.com`
-- **Target Access**: Network connectivity to your applications
-
-## Step 1: Create Your Private Location
-
-Navigate to [Private Locations](https://app.checklyhq.com/private-locations) and click "New private location":
-
-
-
-Provide a descriptive name and choose an icon that represents your location or environment.
-
-## Step 2: Secure Your API Key
-
-Copy and securely store the generated API key. This key authenticates your agents with Checkly:
-
-
-
-
-The API key is only shown once during creation. Store it securely in your secrets management system.
-
-
-## Step 3: Deploy Your First Agent
-
-Start a Checkly Agent using Docker:
-
-```bash
-docker run -e API_KEY="pl_your_api_key_here" -d checkly/agent:latest
-```
-
-For production deployments, consider:
-- Using specific version tags instead of `latest`
-- Using the [dev image](/platform/private-locations/dev-agent) if your checks require native modules
-- Configuring resource limits and restart policies
-- Setting up monitoring and logging for the agent containers
-
-## Step 4: Verify Agent Connection
-
-Refresh your Private Locations page to see your active agents:
-
-
-
-The interface shows:
-- Number of active agents
-- Last connection time
-- Agent health status
-
-## Step 5: Configure Your Checks
-
-When creating checks, select your Private Location from the available locations:
-
-
-
-Deselect other locations to ensure your checks run exclusively from your Private Location.
-
-## Resource Requirements
-
-
-**Memory Guidelines:**
-- API checks: ~150MB per concurrent check
-- Browser checks: ~1.5GB per concurrent check
-- Minimum recommended: 2 CPU cores, 4GB RAM for mixed workloads
-
-
-## Next Steps
-
-Once your first agent is running, explore these advanced topics:
-
-
-
-Learn advanced agent configuration options, environment variables, and production settings
-
-
-
-Deploy Private Locations on Kubernetes for production-scale monitoring
-
-
-
-Explore real-world examples and deployment patterns
-
-
-
-Integrate Private Locations with monitoring-as-code workflows
-
-
-
-
-Start small with a single agent to test connectivity and functionality, then scale based on your monitoring requirements and workload patterns.
-
diff --git a/platform/private-locations/scaling-redundancy.mdx b/platform/private-locations/scaling-redundancy.mdx
index e955ef16..d5416093 100644
--- a/platform/private-locations/scaling-redundancy.mdx
+++ b/platform/private-locations/scaling-redundancy.mdx
@@ -1,6 +1,6 @@
---
title: 'Scaling and Redundancy'
-description: 'Plan capacity, implement redundancy, and scale Checkly Private Locations for production workloads. Learn sizing calculations, scaling strategies, and high availability patterns.'
+description: 'Plan capacity, implement redundancy, and scale Checkly Private Locations for production workloads.'
---
diff --git a/platform/private-locations/use-cases.mdx b/platform/private-locations/use-cases.mdx
deleted file mode 100644
index b91cd28d..00000000
--- a/platform/private-locations/use-cases.mdx
+++ /dev/null
@@ -1,309 +0,0 @@
----
-title: 'Private Locations Use Cases & Examples'
-description: 'Explore real-world examples and deployment patterns for Private Locations. Learn how to monitor internal systems, databases, microservices, and meet compliance requirements.'
-sidebarTitle: 'Use Cases'
----
-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:
-
-```bash
-# 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:
-
-```typescript
-// 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:
-
-```typescript
-// 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:
-
-```bash
-# 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:
-
-```typescript
-// 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:
-
-```typescript
-// 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:
-
-```bash
-# 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:
-
-```typescript
-// 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:
-
-
-
-Learn advanced configuration options and environment variables
-
-
-
-Deploy at scale with Kubernetes orchestration
-
-
-
-Integrate with monitoring-as-code workflows
-
-
-
-Plan for growth and implement redundancy
-
-