Third-Party Dependencies
Your storefront depends on services you don't operate: a consent manager CDN, payment provider JavaScript, review widgets, a tag manager. When one of them breaks, your own uptime checks stay green — but consent stops being collected, payments fail, or widgets disappear.
Dependency checks monitor those external URLs directly, and they assert on what the response contains and how big it is, not just the status code.
Why Status Codes Aren't Enough
Third-party providers rarely fail with an error status. Real-world failure modes:
- A consent manager CDN exhausts its plan quota and serves a 39-byte stub with HTTP 200 —
console.warn('Quota exceeded')— instead of the ~300 KB consent script. No banner, no consent collected, analytics firing for every visitor. - A payment provider deprecates an API version and starts returning 404s only for some endpoints.
- A widget vendor ships a broken release that returns an HTML error page — with HTTP 200.
A conventional uptime check on any of these reports "up". A dependency check catches all three.
Setting Up a Dependency Check
- Open your site in Pulsar
- Find the Third-Party Dependencies card
- Click Add Dependency
- Enter the exact URL your storefront loads (copy it from your page source or the browser's Network tab)
Assertions
| Assertion | Triggers an alert when… | Example |
|---|---|---|
| Error patterns | The response contains any pattern | Quota exceeded |
| Required patterns | The response is missing any pattern | A function name your integration relies on |
| Minimum response size | The response body is smaller than N bytes | A healthy consent script is 200+ KB; a failure stub is under 1 KB |
Pattern matching is case-insensitive substring matching. All assertions apply even when the response is HTTP 200.
The minimum response size is the most robust assertion for script CDNs — you don't need to predict the failure message, only know that a healthy response is never tiny. Check the current size with:
curl -s -o /dev/null -w "%{size_download} bytes\n" 'https://cdn.example.com/app.js?key=...'
Then set the minimum to roughly half of the healthy size.
Behaviour
- Dependency checks run on the site's check interval by default; you can set a per-dependency interval (minimum 1 minute).
- They run independently of the site's own status — a third-party outage is detected even while your storefront is up, and vice versa.
- Failures are confirmed with a retry before alerting (the same anti-false-positive logic as HTTP checks), and alerts auto-resolve on confirmed recovery.
- A failing dependency raises a Dependency Failing alert, which pages instantly through all your notification channels — it is treated as an incident, not rolled into the daily digest.
- Each site can monitor up to 20 dependencies.
What to Monitor
Good candidates for a Magento store:
| Dependency | Why |
|---|---|
| Consent manager script (CCM19, Usercentrics, Cookiebot…) | If it breaks, tracking may run without consent — see Consent Guard for full coverage |
| Payment provider JS (Mollie, Stripe, PayPal…) | Checkout silently degrades when it fails |
| Review / trust widgets (Trusted Shops, Trustpilot…) | Conversion impact, CSP breakage |
| Tag manager container | All downstream analytics depend on it |
Related
- Consent Guard — behaviour-level detection of a consent setup that "fails open"
- Browser Checks — capture the
console.warnmessages third-party scripts emit when they degrade