NIST AU-6 requires ongoing monitoring of system activity, which includes the health of external dependencies your system relies on. A Stripe outage that takes down your checkout flow is functionally indistinguishable from your own application failing — from the user's perspective, payments are broken. The difference is your response: if you know Stripe is the cause within two minutes, you update your status page and notify users; if you spend 45 minutes debugging your own code first, your response is slower and your customers are angrier. Third-party service health monitoring is free (status page subscriptions) and takes minutes to configure — the gap between "configured" and "not configured" is purely awareness.
Low because third-party outages are outside your control, but monitoring them significantly reduces time-to-correct-diagnosis during incidents involving external dependencies.
Subscribe to the status pages of your critical dependencies so you receive email or Slack alerts the moment they report an incident.
Key subscriptions for most SaaS products:
Document subscriptions in docs/operations.md:
## Third-Party Status Pages
- Stripe: https://status.stripe.com (subscribed: email + #ops Slack)
- Supabase: https://status.supabase.com (subscribed: email)
- Vercel: https://www.vercel-status.com (subscribed: email)
For automated monitoring, your uptime tool (Better Stack, Pingdom) can add external URL checks that alert when a vendor status page stops returning 200.
ID: saas-logging.observability.third-party-health-monitored
Severity: low
What to look for: Enumerate all relevant files and Look for any mechanism that monitors the health of external services the application depends on. Check for: subscriptions to status pages of key dependencies (Stripe, Supabase, GitHub, SendGrid, Resend, Twilio, etc.) via Statuspage.io RSS feeds or email alerts, health check integrations in the monitoring service that ping third-party endpoints, or documentation of which third-party services are monitored and how. Look in README, docs/, or runbooks for references to vendor status pages.
Pass criteria: No more than 0 violations are acceptable. Evidence that external service health is monitored, even informally: documented status page subscriptions, a monitoring rule that checks a critical third-party endpoint, or runbook guidance about which status pages to check during incidents.
Fail criteria: No evidence of any third-party health monitoring. No status page subscriptions documented, no external endpoint checks.
Skip (N/A) when: Application has no meaningful third-party service dependencies (no payment processor, no email service, no external APIs). Signal: no Stripe, Resend, SendGrid, Twilio, external auth provider, or similar service dependencies in package.json or .env.example.
Detail on fail: "No third-party service health monitoring documented — application depends on Stripe and Resend but no status page subscriptions or monitoring rules found"
Remediation: When Stripe has an outage, knowing about it within minutes (before your users tell you) lets you respond proactively. Status page subscriptions are free and take two minutes to set up.
Subscribe to the status pages of your critical dependencies:
Document these in docs/operations.md so the whole team knows where to check during incidents:
// docs/operations.md
## Third-Party Status Pages
- Stripe: https://status.stripe.com (subscribed: email + Slack)
- Supabase: https://status.supabase.com (subscribed: email)
- Vercel: https://www.vercel-status.com (subscribed: email)
For automated monitoring, your uptime monitoring service (Better Stack, Pingdom) can add external URL checks.