Uptime vs page speed monitoring for indie SaaS
Uptime answers: did this URL return the expected HTTP status on a schedule? Page speed answers: how fast did a real browser render this marketing page? Confusing the two leads to green dashboards while customers see a white screen for ten seconds, or red alerts because /health never cared about LCP.
StillOnline keeps both in one project: Monitoring tab for HTTP checks and your public status page; PageSpeed tab for scheduled PSI on public marketing URLs (full Page Speed guide). This page is the decision map, not a second PSI deep dive.
Quick answer
Monitor API /health (or product URL) on the Monitoring tab for uptime, status page, and owner alerts (Telegram). Use PageSpeed on Pro for /, pricing, or blog URLs where load time matters. Page Speed does not replace health checks and is not shown on the public status page. One-off Lighthouse tabs do not replace scheduled history in StillOnline.
Side-by-side
| Question | Uptime (Monitoring) | Page speed (PageSpeed tab) |
|---|---|---|
| Typical URL | https://api.app.com/health | https://www.app.com/pricing |
| Metric | HTTP status, probe interval | PSI Performance, LCP, CLS, INP |
| Customer status page | Yes | No |
| Owner alert on failure | Email / Telegram / Slack | No performance push (by design) |
| Free tier | 1 URL, 5 min probes | Upgrade hint only |
| Auth required on URL | Should be public GET | Must be public (no login) |
When you only need uptime
Ship uptime first if you are pre-revenue or API-only.
- Backend SaaS with JSON clients
- Webhooks and workers without a marketing site
- Incident comms matter more than LCP on
/blog
Start: health URL quickstart · public status page.
When to add page speed
Add PageSpeed when conversion surfaces load slowly often enough to hurt signups.
- Pricing or landing changed hero images or fonts
- SEO team asks for CWV history next to deploy dates
- Support says “site feels slow” but API health is 200
Cap URLs: 3 on Pro, 5 on Ultimate (Page Speed guide).
Anti-patterns
| Mistake | Fix |
|---|---|
PageSpeed on /api/health | Meaningless JSON render score — use Monitoring |
Uptime only on marketing / | API can die while homepage is up |
| One PSI run after deploy | Schedule repeats in PageSpeed tab |
| Expect Telegram when Performance drops | Tune marketing; uptime alerts stay on checks |
False greens on uptime still happen with redirects and WAF: probe guide.
Related guides
- Page speed monitoring (PSI) on StillOnline
- Health check URL quickstart
- Side project production checklist
- Best uptime tools for indie SaaS 2026
FAQ
Does StillOnline page speed monitoring replace uptime checks?
No. They are separate tabs and schedules. Uptime drives the status page and owner alerts; PageSpeed stores PSI history for public marketing URLs. Page Speed guide.
Can customers see Core Web Vitals on my StillOnline status page?
Not in v1. The public page reflects HTTP check components and incidents, not Lighthouse scores.
Should I monitor /app dashboard load time?
Authenticated app shells are a poor PSI target. Monitor marketing URLs on PageSpeed and API health on Monitoring.
Do StillOnline probes measure TTFB for API health?
Probes record status and timing, but alerts are based on expected status code, not LCP. Use PageSpeed for render metrics.
Telegram alerts for slow pricing page?
Owner alerts follow check down/recovery, not Performance score. Fix uptime on /health; investigate slowness via PageSpeed tab and deploy notes.