Script icon
Docker icon
If icon
SlackIncomingWebhook icon
Log icon
Return icon
Schedule icon

Pingdom Uptime Check Failing Probe Sentinel

Audits Pingdom global uptime checks for regional probe failures, detects edge routing blackouts, and delivers Slack alerts to SRE teams.

Categories
CloudInfrastructure

Enterprise software platforms rely on external synthetic monitoring to verify that customer-facing domains, load balancers, and edge content delivery networks (CDNs) remain reachable across the global internet. Pingdom operates distributed probe clusters across North America, Europe, Asia-Pacific, and Latin America to simulate real client HTTP/HTTPS requests. However, when origin TLS certificates expire, DNS Anycast routes flap, or cloud provider edge firewalls mistakenly drop synthetic user-agent traffic, endpoints drop offline without triggering internal application errors. If teams rely solely on email alerts or delayed weekly digest reports, Mean Time to Resolution (MTTR) stretches into hours. This sentinel polls the Pingdom REST API v3.1 every 10 minutes, checks operational uptime and response latency, and delivers high-priority incident notifications to SRE channels on Slack with direct links to Pingdom root-cause waterfall diagnostics.

How it works

  1. Scheduled triggering: Executes every 10 minutes via automated cron trigger (*/10 * * * *) or runs on-demand via manual execution.
  2. Check status query: Invokes the Pingdom REST API v3.1 endpoint /api/3.1/checks/{check_id} using a secured bearer token.
  3. Probe metrics evaluation: Inspects the operational status attribute and measures lastresponsetime against configured latency thresholds.
  4. Threshold comparison: Verifies whether the endpoint is non-responsive (status != up) or if response latency exceeds max_response_time_ms_threshold.
  5. Conditional alerting: An io.kestra.plugin.core.flow.If flowable checks if an outage or degradation occurred and dispatches a Slack alert to #sre-critical-incidents.
  6. Manifest export: Emits a structured JSON audit payload containing probe telemetry for monthly availability calculations and SLA compliance dashboards.

Architecture diagram

flowchart TD
  A[ten_minute_pingdom_audit Schedule Trigger] --> B[evaluate_pingdom_check_status Python Script]
  B --> C[check_probe_status Flowable If]
  C -- Endpoint Down or Slow --> D[notify_slack_pingdom_down Webhook]
  C -- Probe Operational --> E[log_uptime_probe_status Log]
  D --> E
  E --> F[export_pingdom_manifest Return]

What you get

  • Out-of-band detection of public endpoint availability drops verified by global synthetic probes.
  • Immediate incident escalation to Slack channels with direct triage URLs and latency metrics.
  • Protection against false alarms by aggregating probe statuses before alerting.
  • Structured JSON uptime records supporting contractual Service Level Agreement (SLA) reporting.

Who it's for

  • Site Reliability Engineers (SREs) monitoring corporate domain, API gateway, and ingress availability.
  • Incident Response Commanders handling high-severity website and service outage triage.
  • Network and Infrastructure Engineers maintaining multi-cloud Anycast routing and global CDN distributions.

Why orchestrate this with Kestra

Pingdom provides high-fidelity global synthetic probes, but connecting external probe status to automated multi-channel incident response workflows requires flexible workflow orchestration. Kestra queries the Pingdom REST API on a reliable schedule, validates check health, formats actionable incident alerts, and triggers downstream remediation actions. With Kestra's containerized Python runner and native secret management, teams automate synthetic uptime verification without writing custom daemons.

Use cases

  • Global DNS and Anycast Routing Blackout Detection: Catch localized BGP or Anycast routing drops where an endpoint is unreachable in Europe while remaining operational in North America.
  • Production TLS Certificate Expiration Guardrail: Detect when synthetic probes fail due to certificate verification handshake errors before real customers are blocked.
  • Post-Deployment Availability Verification: Trigger synthetic probe audits immediately following critical infrastructure cutovers to confirm end-to-end edge connectivity.

Inputs

Name Type Default Description
pingdom_check_id INT 12345678 Numeric identifier of the target Pingdom synthetic uptime check to evaluate.
max_response_time_ms_threshold INT 2000 Maximum allowable response latency in milliseconds before flagging degraded performance.
alert_on_downtime BOOL true Whether to dispatch automated Slack incident notifications when endpoint outages or latency spikes occur.

Expected outputs

  • {{ outputs.evaluate_pingdom_check_status.vars.check_name }}: Display name of the evaluated Pingdom uptime check.
  • {{ outputs.evaluate_pingdom_check_status.vars.hostname }}: Target domain or IP address inspected by the check.
  • {{ outputs.evaluate_pingdom_check_status.vars.is_down }}: Boolean flag indicating whether the endpoint was declared down by Pingdom probes.
  • {{ outputs.export_pingdom_manifest.value }}: Structured dictionary containing the consolidated uptime check diagnostic manifest.

Prerequisites

  • Outbound HTTPS network access from Kestra execution workers to api.pingdom.com.
  • A Pingdom API token with read permissions for the Checks resource.
  • A Slack Incoming Webhook URL configured in Kestra secrets.

Secrets

  • PINGDOM_API_TOKEN: Pingdom API bearer token with permissions to query check statuses and probe metrics.
  • SLACK_WEBHOOK_URL: Slack Incoming Webhook URL used to dispatch critical uptime incident notifications.

Quick start

  1. Register PINGDOM_API_TOKEN and SLACK_WEBHOOK_URL in your Kestra secret storage.
  2. Import this blueprint into your Kestra instance under the company.uptime namespace.
  3. Update pingdom_check_id with your check numeric ID (found in the Pingdom dashboard URL).
  4. Run a manual execution to test Pingdom API authentication and verify the structured output.

Common pitfalls and troubleshooting

  • API Token Header: Pingdom API v3.1 requires Authorization: Bearer <TOKEN>; older legacy multi-token username/password headers are deprecated.
  • Check Resolution Frequency: Pingdom checks typically poll on 1-minute or 5-minute intervals; ensure the Kestra schedule aligns with probe resolution cycles.
  • Maintenance Windows: If Pingdom checks are placed in scheduled maintenance, the API returns a status of paused; the sentinel handles paused states gracefully.

How to extend

  • Automated Route 53 DNS Failover: Trigger an automated AWS Route 53 health check override or secondary origin traffic shift when downtime is detected.
  • PagerDuty P1 Escalation: Dispatch an immediate high-urgency incident to PagerDuty or Opsgenie if the outage persists across two consecutive checks.
  • Multi-Probe Suite Monitoring: Wrap the evaluation in an io.kestra.plugin.core.flow.ForEach loop to audit all primary public corporate endpoints.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.