Stripe Is Down. Razorpay Is Slow. Your Monitor Says Green.

Your monitoring dashboard is green. Your server is responding. Your status page says "All Systems Operational."

Meanwhile, your Razorpay checkout widget never loaded. Your Auth0 login SDK timed out. Your Cloudflare edge is routing users to a saturated PoP. Every user who hit your product in the last 20 minutes experienced one of these failures. None of them are visible to your monitoring system, because your monitoring system is watching your server — not the network of third-party dependencies your product depends on to actually function.

This is the third-party dependency monitoring problem. It is the single largest source of unmonitored downtime for modern SaaS products, and it is systematically invisible to the monitoring tools most teams use.

Why Third-Party Failures Are Invisible to Uptime Monitors

Understanding this gap requires understanding exactly what an HTTP uptime monitor measures.

When your monitor pings https://app.yoursaas.com/checkout, here is what happens:

1. The monitor sends an HTTP GET request from a probe server.
2. Your server receives the request and returns the HTML of the checkout page.
3. The monitor records the response code (200 OK) and response time.
4. The check passes.

Here is what the monitor does not do:

• Open the response in a browser
• Execute the JavaScript in the response
• Load the Razorpay checkout.js script from Razorpay's CDN
• Render the payment widget
• Verify that the payment button is clickable
• Confirm that clicking "Pay" actually initiates a payment request

All of those steps — the ones that determine whether a customer can actually pay — happen in the browser, after your server has already returned 200 OK. Your server's work is done. The monitor declared success. The user's experience hasn't even started yet.

The Most Common Third-Party Failure Sources

Here are the third-party dependencies that cause the most user-visible outages, ranked by frequency and severity for Indian SaaS products:

1. Payment gateways (Razorpay, Stripe, PayU, Cashfree)

Payment JavaScript widgets are loaded from the payment provider's CDN at checkout time. If the CDN has an issue — even a partial one affecting specific edge nodes — the widget fails to load in some users' browsers. The checkout page returns 200 OK. Users see a blank payment section with no button to click.

Razorpay and Stripe both have excellent global infrastructure with high uptime. But "high uptime" at the aggregate level masks CDN edge node issues that affect specific geographic regions for 15–60 minute windows several times per year. For Indian SaaS products, Razorpay CDN issues in specific Indian cities are the most common source of payment failures that uptime monitoring misses.

2. Authentication providers (Auth0, Firebase Auth, Clerk, Supabase Auth)

Auth SDKs are loaded from third-party CDNs. A CDN issue, a rate-limiting problem, or an Auth provider API degradation can prevent the auth SDK from loading or initialising — making the login form non-functional while the login page returns 200 OK.

Auth0 and Firebase Auth both have status pages. But by the time their status page reflects an incident, your users have already been unable to log in for 15–30 minutes.

3. CDN and network infrastructure (Cloudflare, AWS CloudFront, Fastly)

A Cloudflare edge node issue can cause elevated latency or errors for a geographic subset of your users without affecting your origin server at all. Your uptime monitor — which may be checking from a location that routes through a healthy edge node — sees no problem.

In 2024, multiple Cloudflare incidents affected specific regional PoPs while the service's overall status showed "operational." Teams monitoring only their origin server missed these incidents entirely.

4. Analytics and session recording (Segment, Mixpanel, FullStory)

Analytics tools are usually non-critical from a user perspective — if Segment has an outage, your product still works. The risk is the opposite: analytics scripts that load synchronously or block rendering due to a CDN issue can delay your entire page load, creating a performance degradation incident caused by a tool your users don't care about.

5. Communication services (Twilio, SendGrid, Postmark)

If your product sends transactional emails (signup confirmation, password reset, invoice delivery), a SendGrid or Postmark outage doesn't break your product — it breaks your user's ability to access your product. A password reset that never arrives is effectively a login failure.

Third-Party vs First-Party Monitoring

The critical insight: the only monitoring approach that catches third-party failures is synthetic browser monitoring — running a headless browser, loading your actual pages, and verifying that the full user experience works, including all third-party dependencies.

The Checkout Failure That Status Pages Won't Show You

Here is a scenario that happens regularly and is systematically undetected by conventional monitoring.

A Razorpay CDN edge node serving traffic from Bengaluru begins experiencing elevated latency. The root cause is a routing issue affecting a specific peering point. Razorpay's global infrastructure is healthy. Their status page shows "Operational." Your server is healthy. Your uptime monitor shows green.

But users connecting from Bengaluru ISPs routed through the affected peering point experience 15–30 second timeouts when their browser tries to load checkout.js. Most give up. A subset successfully loads the page (because their specific network path avoids the affected edge). You see checkout conversion drop by 45% in your analytics — if you're checking it. You don't receive any monitoring alert, because no alert is configured for "Razorpay widget fails to load from Bengaluru."

Synthetic monitoring from Bengaluru would catch this in the next check cycle. Without it, you find out from analytics, or from support tickets, or from a customer WhatsApp message — typically 45–120 minutes into the incident.

How to Monitor Third-Party Dependencies

The fundamental solution is Playwright-based synthetic monitoring that loads your actual pages in a real browser and verifies that third-party components rendered correctly.

// PingSLA Synthetic Check: Razorpay Checkout Widget Verification
const { chromium } = require('playwright');

async function verifyRazorpayCheckout() {
  const browser = await chromium.launch();
  const page = await browser.newPage();

  try {
    await page.goto('https://yourstore.in/checkout', {
      waitUntil: 'networkidle',
      timeout: 20000
    });

    // Step 1: Verify page loaded with product information
    await page.waitForSelector('[data-testid="product-summary"]', { timeout: 5000 });

    // Step 2: Verify Razorpay widget script loaded
    // This check confirms the script tag was loaded, not just that the page returned 200
    const razorpayLoaded = await page.evaluate(() => {
      return typeof window.Razorpay !== 'undefined';
    });

    if (!razorpayLoaded) {
      throw new Error('Razorpay SDK not loaded — CDN or CSP failure');
    }

    // Step 3: Verify payment button is visible and enabled
    await page.waitForSelector('[data-testid="pay-now-btn"]:not([disabled])', { timeout: 8000 });

    // Step 4: Check that the payment button triggers Razorpay (without completing payment)
    // Monitor: click button, verify Razorpay modal appears (not just the page event)
    await page.click('[data-testid="pay-now-btn"]');
    await page.waitForSelector('.razorpay-container', { timeout: 5000 });

    return { status: 'pass', provider: 'razorpay', widgetLoaded: true };

  } catch (error) {
    return {
      status: 'fail',
      error: error.message,
      // Classify the failure type for better alerting
      failureType: error.message.includes('Razorpay SDK') ? 'third-party-cdn' : 'checkout-flow'
    };
  } finally {
    await browser.close();
  }
}

The key difference from a standard page load check: this script verifies window.Razorpay !== undefined — confirming the third-party JavaScript actually loaded and initialised. Then it verifies the payment button is visible and clickable. Then it confirms the Razorpay modal appears on click. A CDN issue anywhere in the Razorpay stack would fail one of these three checks.

Using PingSLA's Checkout Defender for Third-Party Payment Monitoring

PingSLA's Checkout Defender is specifically designed for this scenario. It:

• Loads your checkout page in a headless browser from Indian probe locations (BLR, Mumbai, Chennai)
• Verifies that the payment gateway SDK (Razorpay, Stripe, PayU) loaded and initialised
• Checks that payment UI elements are rendered and interactive
• Tests the payment initiation flow without completing a real transaction
• Alerts via WhatsApp, Slack, or PagerDuty if any third-party component fails to load

This gives you visibility into the payment experience your users are actually having — not just whether your server returned 200 OK.

How do I monitor third-party services I don't control?

Use synthetic browser monitoring — automated headless browser scripts that load your actual product pages and verify that third-party components (payment widgets, auth SDKs, analytics scripts) loaded and functioned correctly. HTTP uptime monitoring cannot detect third-party failures because it checks only your server's response, not what happens in the user's browser after your page loads.

What is third-party dependency monitoring?

Third-party dependency monitoring is the practice of checking whether external services your product depends on — payment gateways, authentication providers, CDNs, email services — are functioning correctly from your users' perspective. Since you don't control these services, you can't monitor them directly. Instead, you monitor the user-facing outcome: does the payment widget render? Does the auth SDK initialise? Does the checkout flow complete?

How do I know if Razorpay is causing checkout failures on my site?

Set up a synthetic monitor that loads your checkout page in a headless browser and explicitly checks whether the Razorpay SDK loaded (via window.Razorpay !== undefined) and whether the payment UI elements rendered. If the check fails on this assertion — rather than on a server response code — you know the failure is Razorpay-side. You can also cross-reference with Razorpay's status page, but note that status pages often lag behind actual incidents by 15–30 minutes.

Does uptime monitoring catch third-party failures?

No. HTTP uptime monitoring checks whether your server returns a successful response code. Third-party failures (CDN issues, SDK load failures, API degradations at external providers) occur after your server has already returned 200 OK, during the browser's resource loading phase. They are structurally invisible to server-side monitoring and can only be detected by monitoring that runs a real browser.

Which third-party services should Indian SaaS products monitor specifically?

Priority order: (1) Payment gateway — Razorpay, Stripe, or PayU, depending on your stack; checkout failures are the highest-revenue-impact failure. (2) Authentication provider — Auth0, Firebase, Clerk, or Supabase. (3) CDN — Cloudflare or CloudFront; regional issues are common. (4) Email provider — SendGrid, Postmark, or SES for transactional email. (5) Any third-party script that loads synchronously or affects rendering.

When was the last time you actually verified your Razorpay widget loads in Bengaluru? PingSLA's Checkout Defender runs a full browser-based checkout flow verification from Indian probe locations — free, no account required.

For continuous third-party dependency monitoring with 5-minute synthetic checks from BLR, Mumbai, and Chennai, see PingSLA plans.

Related reading: Your Checkout Is Broken Right Now · Synthetic Monitoring Explained · Razorpay Checkout Monitoring India