tutorial

Monitoring Paddle with Vigilmon: Payment API Uptime, Webhook Delivery, Checkout Health & SSL Certificate Checks

How to monitor Paddle payment infrastructure with Vigilmon — payment API availability, webhook endpoint health, checkout page uptime, SSL certificate monitoring, and status page alerting for 2026.

Paddle is a merchant of record and payment infrastructure provider used by SaaS companies worldwide to handle subscriptions, one-time purchases, tax compliance, and billing. When Paddle has an incident — API degradation, checkout latency spikes, webhook delivery failures — your customers cannot purchase, upgrade plans, or complete transactions. Revenue stops. Vigilmon gives you an external, independent monitoring layer on top of Paddle's own status page: payment API availability, your webhook receiver endpoints, checkout page health, and SSL certificate expiry on your billing domain.

What You'll Build

  • A monitor on Paddle's payment API endpoint for external availability tracking
  • A webhook receiver health check confirming your endpoint is accepting Paddle events
  • A checkout page monitor catching frontend degradation before customers hit it
  • SSL certificate monitoring for your billing and checkout domains
  • Alerting configured to catch payment outages within seconds

Prerequisites

  • A Paddle account (Paddle Classic or Paddle Billing)
  • A webhook receiver endpoint deployed and publicly accessible
  • A free account at vigilmon.online

Step 1: Monitor the Paddle API Availability

Paddle's REST API drives subscription management, pricing queries, and transaction processing for your application. When the API degrades, your backend cannot create checkout sessions, fetch subscription data, or process billing events. Paddle publishes its API at api.paddle.com (Paddle Billing) or vendors.paddle.com (Paddle Classic):

curl -I https://api.paddle.com/

A reachable Paddle API returns a response (typically 404 or 401 at the root — what matters is that the host resolves and TLS handshakes). Add a monitor targeting a known stable endpoint:

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://api.paddle.com/products (Paddle Billing) or https://vendors.paddle.com/api/2.0/product/get_list (Classic).
  3. Check interval: 60 seconds.
  4. Expected status: 200 or 401 (either confirms the API is responding).
  5. Label: Paddle API - Availability.
  6. Click Save.

Classic vs Billing: If you are on Paddle Classic, use vendors.paddle.com. If you migrated to Paddle Billing, use api.paddle.com. The two APIs are separate infrastructure.

Step 2: Monitor Your Webhook Receiver Endpoint

Paddle delivers subscription lifecycle events — subscription.created, transaction.completed, subscription.cancelled — to a webhook URL you control. If your webhook receiver is down, Paddle retries delivery but events queue up and your application's subscription state drifts from reality. Undelivered webhooks cause provisioning failures, missed cancellations, and incorrect billing states.

Add a basic availability monitor on your webhook endpoint:

  1. Add Monitor → HTTP.
  2. URL: https://your-app.example.com/webhooks/paddle.
  3. Check interval: 60 seconds.
  4. Expected status: 200 or 405 (many frameworks return 405 Method Not Allowed for GET on a POST-only route — that confirms the endpoint is up and routing correctly).
  5. Label: Paddle Webhook Receiver.
  6. Click Save.

Why 405 is acceptable: Your webhook endpoint should only accept POST requests from Paddle. A GET probe returning 405 confirms the application is running and the route is registered. A 502 or 503 means the app server is down.

Step 3: Monitor Your Checkout Page

Paddle-powered checkout flows can be embedded (overlay or inline checkout via paddle.js) or hosted on your own domain with Paddle's checkout SDK. Either way, the page that initiates a purchase must be available and load successfully. Add a monitor on the pricing or checkout initiation page customers see:

curl -I https://your-app.example.com/pricing

Add the monitor:

  1. Add Monitor → HTTP.
  2. URL: https://your-app.example.com/pricing (or /upgrade, /checkout — wherever Paddle checkout is initiated).
  3. Check interval: 60 seconds.
  4. Expected status: 200.
  5. Keyword: paddle (present in the page if paddle.js is loaded; adjust to a keyword present in your pricing page HTML).
  6. Label: Paddle Checkout Page.
  7. Click Save.

Paddle overlay checkout: If you use Paddle's overlay checkout, the checkout form is served from Paddle's CDN. Your monitor on the pricing page confirms your side of the checkout flow is healthy. Monitor api.paddle.com (Step 1) to catch the Paddle-side degradation.

Step 4: Monitor SSL Certificates

Payment pages and billing domains are high-trust targets — an expired TLS certificate on your checkout or billing subdomain will cause browsers to display certificate warnings, blocking purchases entirely. Your customers cannot tell the difference between a certificate error and a security incident; they will leave.

curl -v https://your-app.example.com 2>&1 | grep -i "expire"

Add SSL monitoring:

  1. Add Monitor → SSL Certificate.
  2. Domain: your-app.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

If you have a separate billing subdomain (billing.your-app.example.com), add a second SSL monitor for it. Payment infrastructure deserves multiple certificate monitors.

Step 5: Track Paddle's Status Page

Paddle publishes their system status at status.paddle.com. Rather than checking it manually during incidents, add a Vigilmon keyword monitor that alerts when Paddle reports a service disruption:

  1. Add Monitor → HTTP.
  2. URL: https://status.paddle.com/.
  3. Check interval: 5 minutes.
  4. Expected status: 200.
  5. Keyword: All Systems Operational (present when everything is healthy; absent during incidents).
  6. Label: Paddle Status Page.
  7. Click Save.

What this gives you: When Paddle has an incident, the keyword match fails and Vigilmon alerts you — without you needing to check their status page manually. Combine this with your API monitor to distinguish Paddle-side outages from problems on your infrastructure.

Step 6: Configure Alerting

In Vigilmon under Settings → Notifications, configure alert channels for your team:

| Monitor | Trigger | Action | |---|---|---| | Paddle API - Availability | Non-2xx/4xx or timeout | Paddle API incident; check status.paddle.com; enable maintenance mode on checkout | | Paddle Webhook Receiver | Non-200/405 or timeout | App server down; webhook events will queue and replay; fix application server first | | Paddle Checkout Page | Non-200 or keyword missing | Application issue; new purchases will fail; investigate app server and paddle.js loading | | Paddle Status Page | All Systems Operational missing | Paddle-side incident; pause paid ad campaigns; alert support team | | SSL Certificate | < 30 days to expiry | Renew certificate immediately; payment page certificate errors block all purchases |

Alert sensitivity: Set payment-related monitors to alert after 1 consecutive failure. A single missed check on a payment API is worth the alert — false positives from payment monitors are far less costly than a missed outage.

Revenue impact alerting: Route Paddle monitor failures to your highest-urgency channel (PagerDuty, on-call rotation). Every minute of checkout unavailability is measurable lost revenue.

Common Paddle Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Paddle API incident (upstream) | API Availability fires; Status Page keyword fails | | Your webhook receiver app crashes | Webhook Receiver fires; API monitor stays green | | Your checkout page returns 500 after a deploy | Checkout Page fires; API monitor stays green | | SSL certificate expires on billing domain | SSL monitor alerts at 30-day threshold; browsers block checkout | | CDN misconfiguration serves stale checkout page | Checkout Page keyword check fails | | Paddle DDoS mitigation blocks your requests | API Availability fires with unexpected status | | App server memory exhaustion causes 502s | Webhook Receiver and Checkout Page fire simultaneously | | Paddle maintenance window | Status Page keyword fails; API monitor may fire | | DNS misconfiguration on your checkout domain | Checkout Page and Webhook Receiver fire with DNS errors |

Why Monitor Paddle with an External Tool

Paddle's internal alerting and your application's error tracking cannot catch every failure mode. Your application's error logs do not capture failed purchase attempts when Paddle's API never responds — those are silent failures from your app's perspective. Vigilmon catches what your application cannot see: external API reachability, the customer-facing checkout experience, and webhook receiver availability — monitored from outside your infrastructure with no dependency on your application being healthy.

For a payment provider, minutes matter. A 5-minute checkout outage during a high-traffic marketing campaign is a significant revenue event. External monitoring with sub-minute check intervals is the fastest possible detection mechanism.

Paddle handles the complexity of global payment collection, tax compliance, and subscription billing. Vigilmon handles monitoring that the payment infrastructure — both Paddle's APIs and your application's integration points — is available and healthy from end to end.

Start monitoring your Paddle integration in under 5 minutes — register free at vigilmon.online.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles