How to migrate from Pingdom to StackEye

Pingdom is a capable platform, but for most teams it's expensive relative to what they actually use. The entry-level plan starts at $15/mo and scales steeply. There's no free tier. RUM and transaction testing add cost without adding value for teams that just need reliable uptime alerts. This guide walks you through migrating your Pingdom checks to StackEye — step by step.

Why migrate?

  • Cost — Pingdom's entry-level plan starts at $15/mo; StackEye is $5–$29/mo for most teams, with a permanent free tier for up to 10 monitors.
  • No free tier — Pingdom requires payment from day one. StackEye offers 10 free monitors permanently, no credit card required.
  • Simpler pricing — Pingdom charges separately for RUM and transaction tests. StackEye pricing is flat per tier.
  • Scoped API keys — Pingdom uses account-level API tokens. StackEye supports scoped keys per use case (probes:read, probes:write, etc.).
  • Independent company — Pingdom is owned by SolarWinds. StackEye is an independent company focused solely on uptime monitoring.

Feature mapping

PingdomStackEye equivalent
CheckProbe
Alert policyNotification Channel + alert threshold
IntegrationNotification Channel (Slack, Webhook, Email)
Status pageStatus Page
Uptime checkHTTP Probe
SSL checkSSL Probe (included automatically)
DNS checkDNS Probe
Port checkTCP Probe (Phase 2)
RUMNot in scope (StackEye focuses on active monitoring)
Transaction checkNot in MVP scope
APIREST API with se_<64-hex-chars> API keys

What StackEye does differently

Multi-region consensus alerting

Pingdom can run checks from multiple locations, but alerting logic fires per-location. StackEye uses majority-vote consensus: an alert fires only when the majority of your configured regions report failure simultaneously. This eliminates false positives caused by regional network blips, and every alert notification includes a per-region breakdown so you can see exactly which regions are affected.

Simpler alert state machine

Pingdom has complex alert policies with escalation levels and contact groups. StackEye uses a clean two-state model:

UP → DOWN (2 consecutive failures across majority of regions)
      → Alert created
      → Notification channels triggered

DOWN → UP (1 success)
      → Alert resolved
      → Recovery notification sent

Two failures to avoid false positives. One success for fast recovery. No escalation configuration required.

Step 1: Export your checks from Pingdom

Pingdom doesn't have a native CSV export, but you can retrieve all checks via their API:

# Get your Pingdom API token from Settings → Pingdom API
PINGDOM_TOKEN="your-token"

# Fetch all checks
curl -H "Authorization: Bearer $PINGDOM_TOKEN" \
  "https://api.pingdom.com/api/3.1/checks?limit=250" \
  | jq -r '.checks[] | [.name, .hostname, .resolution] | @csv' \
  > pingdom-export.csv

The CSV contains name, hostname, and resolution (check interval in minutes).

Step 2: Sign up for StackEye

Visit stackeye.io/signup and start your 14-day free trial — all paid features included, no credit card required. Complete the onboarding wizard to create your organization (about 2 minutes).

Step 3: Configure notification channels

Recreate your Pingdom alert integrations before importing probes. Navigate to ChannelsAdd Channel and map each Pingdom integration:

Pingdom integrationStackEye channel type
Email alertEmail
SlackSlack (OAuth)
PagerDutyWebhook
OpsGenieWebhook
Custom webhookWebhook

Use the Send Test button on each channel to confirm it's receiving alerts before you proceed.

Step 4: Convert Pingdom checks to StackEye probes (CLI)

The StackEye CLI imports probes from YAML or JSON. Use the Pingdom API to build a JSON import file:

# Fetch all Pingdom checks and convert to StackEye probe format
PINGDOM_TOKEN="your-token"
curl -H "Authorization: Bearer $PINGDOM_TOKEN" \
  "https://api.pingdom.com/api/3.1/checks?limit=250" \
  | jq '[.checks[] | {
      name: .name,
      url: ("https://" + .hostname),
      check_type: "http",
      method: "GET",
      interval_seconds: (.resolution * 60),
      regions: ["nyc3","sfo3","chi1"],
      expected_status_codes: [200],
      ssl_check_enabled: true,
      follow_redirects: true,
      max_redirects: 10
    }]' \
  > probes.json

Then install the CLI and import:

# Install CLI
brew install stackeye-io/tap/stackeye   # macOS
curl -sSfL https://stackeye.io/install.sh | sh  # Linux

# Authenticate
stackeye auth login

# Preview import (no changes made)
stackeye probe import --file probes.json --dry-run

# Import all probes
stackeye probe import --file probes.json

# Verify
stackeye probe list

Step 5: Import via API (scripted, for large inventories)

For large check inventories, create probes directly via the REST API:

API_KEY="se_..."
PINGDOM_TOKEN="your-token"

curl -H "Authorization: Bearer $PINGDOM_TOKEN" \
  "https://api.pingdom.com/api/3.1/checks?limit=250" \
  | jq -c '.checks[]' \
  | while read -r check; do
      name=$(echo "$check" | jq -r '.name')
      hostname=$(echo "$check" | jq -r '.hostname')
      resolution=$(echo "$check" | jq -r '.resolution')
      interval_sec=$((resolution * 60))

      curl -sX POST https://api.stackeye.io/v1/probes \
        -H "Authorization: Bearer $API_KEY" \
        -H "Content-Type: application/json" \
        -d "{\"name\": \"$name\", \"url\": \"https://$hostname\", \"check_type\": \"http\", \"interval_seconds\": $interval_sec, \"regions\": [\"nyc3\", \"sfo3\", \"chi1\"]}"
    done

Step 6: SSL monitoring

Pingdom includes SSL certificate expiry monitoring as a separate check type. In StackEye, SSL monitoring is built in: every HTTPS probe automatically checks certificate expiry. Warnings fire at 30 days, 14 days, and 7 days before expiry — no separate configuration required.

Step 7: DNS monitoring

If you used Pingdom's DNS check type, create DNS probes in StackEye:

stackeye probe create \
  --name "DNS check: api.example.com" \
  --check-type dns_resolve \
  --url api.example.com \
  --interval 300

Step 8: Status page migration

To migrate your Pingdom status page:

  1. Note your current Pingdom status page URL and subscriber list.
  2. In StackEye, navigate to Status PagesNew Status Page.
  3. Add your imported probes to the page.
  4. Set a custom domain: add a CNAME record pointing status.yourdomain.com to pages.stackeye.io.
  5. Export your Pingdom subscriber emails (Settings → Status Page → Subscribers) and notify them of the new URL.

Step 9: Cutover checklist

Before canceling Pingdom, verify each item:

  • All checks imported as StackEye probes and showing correct status
  • Alert channels configured and tested (Email, Slack, Webhook)
  • SSL monitoring confirmed active for all HTTPS probes
  • Status page live at new URL, subscribers notified
  • API integrations updated (CI/CD scripts, runbooks) to use StackEye API key
  • Team members invited under Settings → Team
  • RUM-dependent dashboards identified (StackEye does not replicate RUM — see below)
  • 48 hours of clean operation with verified alert delivery

What you'll lose

StackEye does not replicate these Pingdom features:

Pingdom featureStatus in StackEye
Real User Monitoring (RUM)Not in scope — StackEye focuses on active synthetic monitoring
Transaction tests (browser)Not in MVP
Traceroute / root cause analysisNot in MVP
Historical reports > 30 days30-day retention in MVP

If RUM is critical to your workflow, consider keeping Pingdom's RUM add-on while switching your uptime monitoring to StackEye for cost savings on that portion.

Troubleshooting

Hostname vs. full URL: Pingdom checks use hostnames; StackEye probes use full URLs. Make sure your import adds the https:// prefix. The jq conversion script above handles this automatically.

Check interval mismatch: Pingdom resolution is in minutes; StackEye intervals are in seconds. A 1-minute Pingdom check = 60 seconds in StackEye. The conversion script multiplies resolution by 60 automatically.

No Pingdom check ID mapping: StackEye assigns new probe IDs on import. Update any external references (runbooks, dashboards, CI scripts) that referenced Pingdom check IDs.

Probe shows DOWN immediately after import: Your URL may resolve to a private IP address. StackEye probes run from regional cloud clusters and cannot reach private networks. Use a StackEye Private Relay agent for internal services.

Start your 14-day free trial →

← Back to Blog