Hybrid cloud environments — workloads split across on-premises data centres and one or more public cloud providers — introduce a specific category of infrastructure failure that neither on-prem monitoring nor cloud-native observability tools are designed to catch.
The failure mode looks like this: your on-prem application server is healthy. Your cloud service is running. But the VPN or Direct Connect link between them is degraded. Cross-environment API calls are timing out. Users are seeing errors. Your internal monitoring shows green across the board because each component, observed from within its own environment, looks fine.
This is the hybrid cloud monitoring gap: the external, user-facing perspective that sits above both environments and tests whether they work together.
This guide covers what to monitor in a hybrid cloud setup, how to think about probe placement, and how external uptime monitoring gives you the vantage point that internal tools structurally cannot provide.
The Challenges of Hybrid Cloud Monitoring
Siloed Visibility
Most monitoring tools are architected for a single environment. Cloud-native tools (AWS CloudWatch, Azure Monitor, GCP Cloud Monitoring) are excellent at observing resources within their respective cloud. On-premises monitoring tools (Zabbix, Nagios, PRTG) are excellent at observing infrastructure within your data centre network.
In a hybrid environment, you need visibility across the boundary — and that boundary is where failures concentrate.
The Connectivity Layer Is Unmonitored
The connectivity between on-prem and cloud — IPsec VPN, AWS Direct Connect, Azure ExpressRoute, GCP Dedicated Interconnect — is critical infrastructure. When it degrades or fails:
- On-prem-to-cloud API calls fail
- Cloud-to-on-prem database connections time out
- Authentication requests that traverse the boundary start failing
- Replication between on-prem and cloud storage breaks silently
Most organizations have no direct monitoring on the cross-environment link itself. They discover it is degraded because an application engineer notices database timeouts or API latency spikes.
DNS Resolution Across Environments
Hybrid environments typically run split-horizon DNS: internal DNS resolvers return private IP addresses for services that have both internal and external endpoints. DNS misconfiguration — or DNS resolver failure — can cause cross-environment lookups to resolve incorrectly or not at all.
This is particularly insidious because DNS failures often manifest as slow timeouts rather than immediate errors, making them hard to distinguish from performance issues.
Multiple Configuration Points = More Failure Modes
On-prem infrastructure runs on hardware you own, with firmware, network configurations, and physical dependencies. Cloud infrastructure runs on provider-managed hardware with its own failure modes. The integration layer (VPN, Direct Connect, DNS, IAM cross-account roles, API gateways) introduces yet more configuration points. Each layer can fail independently, and failures in the integration layer affect both environments simultaneously.
What to Monitor in a Hybrid Cloud Environment
On-Premises Endpoints
Monitor the public-facing endpoints of your on-premises infrastructure:
- On-prem application servers that are internet-accessible: HTTP/HTTPS availability checks
- On-prem API endpoints exposed to cloud services or external consumers: HTTP checks with response code validation
- On-prem management interfaces (if internet-accessible): HTTPS checks
- SSL certificates on any on-prem HTTPS endpoints: certificate expiry monitoring at 30-day warning windows
For on-prem services that are not internet-accessible, external monitoring reaches them only if you expose a health endpoint through your perimeter. This is often worth doing: a lightweight /health endpoint on your internal API gateway, exposed via NAT or a reverse proxy, gives external probes something to check.
Cloud Service Endpoints
Monitor your cloud-hosted services from the outside, independent of cloud-native monitoring:
- Cloud-hosted API endpoints: HTTP/HTTPS checks from external probe regions
- Cloud-hosted web applications: HTTPS checks at application URLs
- Cloud-native services with public endpoints (S3 static site, Azure Blob Storage website, CloudFront distributions): HTTP checks on the public URL
- SSL certificates on cloud-hosted HTTPS endpoints: certificate expiry monitoring
External checks on cloud services catch failure modes that cloud-native monitoring misses: CloudFront cache misconfigurations that serve stale error pages, certificate issues on custom domain CDN configurations, and application-level errors that the cloud load balancer reports as healthy.
VPN and Direct Connect Tunnel Health
The cross-environment connectivity layer deserves dedicated monitoring:
Heartbeat monitoring approach: Run a lightweight script on a server in each environment. The script tests connectivity across the boundary (a simple TCP connection test or HTTP ping to a known endpoint in the other environment), then sends a heartbeat ping to your external monitoring tool. If the heartbeat stops arriving, the cross-environment link has failed.
Example cross-environment health script (runs on cloud VM, tests on-prem endpoint reachability):
#!/bin/bash
# Test connectivity to on-prem endpoint via Direct Connect
if curl -sf --connect-timeout 5 "http://10.0.1.100/health" > /dev/null 2>&1; then
curl -s "https://vigilmon.online/heartbeat/YOUR_HEARTBEAT_ID" > /dev/null
fi
If Direct Connect or VPN is down, the on-prem endpoint is unreachable, the heartbeat does not ping, and your external monitoring fires an alert within minutes.
DNS Resolution Health
For split-horizon DNS environments, monitor DNS resolution explicitly:
- If you run public-facing services that rely on DNS: external HTTP checks implicitly test DNS resolution (a failed DNS lookup causes the HTTP check to fail)
- For internal DNS resolver health: heartbeat monitoring from within each environment, pinging after a successful internal name resolution test
Cross-Environment API Calls
Monitor the end-to-end path of your most critical cross-environment API calls:
- If cloud services call on-prem APIs: the on-prem API endpoint availability directly reflects whether that integration is working
- If on-prem services call cloud APIs: cloud endpoint availability, combined with heartbeat monitoring from your on-prem environment, gives you both sides of the integration
Probe Location Strategy: External Probes vs. Internal
External Probes (What Vigilmon Provides)
External probes run on infrastructure independent of both your on-premises environment and your cloud environments. They test your endpoints from the perspective of the public internet — the same vantage point as your users and external API consumers.
What external probes catch that internal monitoring misses:
- CDN and edge layer failures invisible to cloud-native monitoring
- DNS propagation issues affecting external resolution
- BGP routing failures between your cloud edge and the public internet
- Certificate expiry affecting external connections
- Load balancer misconfigurations that affect external traffic but not internal
The limitation: external probes cannot reach non-internet-accessible endpoints. Services that are only reachable within your private network require either a health endpoint exposed at the perimeter or heartbeat monitoring from inside the environment.
Internal Probes (Heartbeat and Agent-Based)
Internal probes — monitoring agents or heartbeat scripts running inside each environment — test reachability within that environment. They complement external probes by covering:
- Private network endpoints not exposed to the internet
- Cross-environment connectivity via VPN or Direct Connect
- Internal DNS resolution health
- Database and internal service availability
The right model for hybrid environments: external probes for all internet-accessible endpoints, plus heartbeat monitoring from inside each environment for cross-boundary connectivity and private endpoints.
Recommended Monitoring Setup for Hybrid Cloud
| Monitor | Type | What It Tests | |---|---|---| | On-prem application endpoint | HTTPS | On-prem web tier availability + SSL | | Cloud application endpoint | HTTPS | Cloud web tier availability + SSL | | Cloud API gateway | HTTPS | Cloud API availability | | On-prem API endpoint (if public) | HTTPS | On-prem API + SSL | | Cross-environment heartbeat | Heartbeat | VPN/Direct Connect tunnel health |
Configure all HTTPS monitors with SSL certificate monitoring enabled. Set certificate expiry alerts at 30 days for cloud endpoints and 60 days for on-prem endpoints (on-prem certificate renewal processes are often slower).
Configure the cross-environment heartbeat with a 5-minute expected interval and a 2-minute grace period.
Alert Routing for Hybrid Cloud Incidents
Hybrid cloud incidents often require coordination across infrastructure teams. Route alerts appropriately:
- Cloud endpoint failures: cloud operations team and engineering on-call
- On-prem endpoint failures: infrastructure/data centre team and engineering on-call
- Cross-environment heartbeat failures: both teams simultaneously — this is an integration layer failure that requires coordination
Webhook-based alerting to PagerDuty, OpsGenie, or your incident management tool lets you set appropriate escalation policies per monitor type.
Conclusion
Hybrid cloud environments fail at their boundaries — and those boundaries are exactly where most monitoring tools have blind spots. Neither cloud-native monitoring nor on-premises tools observe the integration layer, the cross-environment connectivity, or the user-facing perspective that sits above both.
External uptime monitoring provides the outside-in view that fills this gap: independent probes testing your endpoints from the public internet, combined with heartbeat monitoring from inside each environment for private endpoints and cross-boundary connectivity. Together, they cover what internal tools cannot.
Start monitoring your hybrid environment for free at vigilmon.online — HTTPS checks, TCP monitors, SSL certificate monitoring, heartbeat monitoring, multi-region consensus alerting, and a customer-facing status page. No agent required for external checks. No credit card for the free tier.
Tags: #hybridcloud #monitoring #uptime #devops #aws #azure #gcp #infrastructure #sre