Third-party outages on your StillOnline status page
Stripe, Auth0, and SendGrid fail independently of your deploy. Your /health may return 200 while checkout, login, or email is broken — customers still blame you. A honest status page names the dependency and links to the vendor’s own status site.
StillOnline monitors your HTTPS URLs and hosts stillonline.tech/{locale}/s/{id}. You manually post incidents when a third party degrades — there is no auto-import from status.stripe.com today. This guide shows component naming, update copy, and what not to claim.
Quick answer
When a vendor incident blocks a product feature but your servers respond 200, open a manual incident on StillOnline and mark the matching component (e.g. Payments, Login, Email) as Degraded — not Major outage on API unless your code is down. Link Stripe Status, Auth0 Status, or SendGrid Status in the update body. StillOnline HTTP checks only prove your URLs; watch vendor pages yourself or via RSS. Free includes one public status page per project — pricing.
Map vendors to customer-facing components
| Vendor | Customer symptom | Suggested component | Vendor status |
|---|---|---|---|
| Stripe | Checkout fails, webhooks delayed | Payments or Billing | status.stripe.com |
| Auth0 | Cannot sign in | Login or Authentication | status.auth0.com |
| SendGrid | No transactional email | Email notifications | status.sendgrid.com |
Avoid infra names (postgres-stripe-proxy) on a public page — name components like Dashboard and Payments; see public status page guide.
What StillOnline checks vs what you communicate
| Layer | StillOnline | You |
|---|---|---|
Your /health | Scheduled HTTP GET every 5 min (Free) | Register canonical API health |
| Stripe API reachability from your app | Only if encoded in /health or separate URL | Optional dedicated check on Pro |
| Vendor platform incident | Not auto-synced | Manual incident + vendor link |
Returning 503 from /health when Stripe is down is a product choice — some teams keep 200 on API and degrade only Payments on the status page to avoid false “total outage.”
Incident update template
Title: Degraded — card payments (Stripe incident)
Body:
We are investigating failed checkouts. Stripe reports an ongoing incident: status.stripe.com/incidents/…. Our API and dashboard remain available. We will update within 30 minutes.
First post within minutes — incident template. Resolve when vendor clears and your smoke test passes.
Monitoring hooks you can add
- Webhook ingestion URL — separate check on Pro if checkout depends on Stripe webhooks — webhook monitoring.
- Auth login — StillOnline does not run browser login; monitor
/healthplus vendor status — auth flow limits. - Owner alerts — your HTTP check stays green; subscribe to vendor status emails or post manually.
Related guides
- Webhook ingestion endpoint monitoring
- Public vs private status page
- B2B trust and status pages
- Incident post template
FAQ
Does StillOnline pull Stripe or Auth0 status automatically?
No. You post manual incidents on your hosted page. Link the vendor status URL in each update.
Should I mark API as down when only Stripe fails?
Usually no — use a Payments component Degraded unless your API cannot serve non-payment routes.
Can I add a StillOnline check on status.stripe.com?
You can HTTP-check their status page, but that reflects their uptime, not yours. Better: monitor your checkout health URL if you build one on Pro.
How many components fit indie SaaS on StillOnline Free?
There is no separate component limit on Free — keep the list short (3–5 names customers recognize). One project, one primary HTTP check — see pricing.