Connected Checks
Audit live platform configuration alongside your repo — the things static scanning can't see.
Connected Checks let PulseLight read live config from your deployed platforms (Stripe, Supabase, Vercel, Sentry, etc.) and flag the things that hurt at launch but don’t show up in a repo scan: a Stripe webhook subscribed to no events, a Supabase RLS policy disabled in production, a Sentry project receiving zero events for two weeks.
Available platforms
How Connected Checks work
Each integration uses the platform’s read-only API or management token. PulseLight stores the credential encrypted at rest (KMS) and uses it only at scan time. We never write back to your platform — the checks are evidence-gathering, not config-mutating.
What each platform contributes
Stripe (Billable pillar)
Verifies webhook is configured, subscribed to the events your app actually handles, and not stuck in test mode. Surfaces mis-routed payment_intent.succeeded events.
Supabase (Secure pillar)
Detects RLS disabled on tables that look like user-data stores; public storage buckets; service-role key shape anomalies. Read-only management API.
Vercel (Stable + Secure pillars)
Flags preview deploys with prod-secret leaks, password-protect misalignment between prod and preview, custom-domain verification failures.
Sentry (Stable pillar)
Confirms the Sentry project is receiving events; flags source-map releases missing on the latest deploy.
Clerk (Secure pillar)
Detects dev-key-in-prod instances and surfaces zero-MFA enrolment on production instances with real users.
Per-platform docs (Stripe, Supabase, Vercel, PostHog, Sentry, Clerk, etc.) follow this pattern: setup, what we check, what signals we surface, scope of credentials we need. See the full docs index →