Staging vs production monitoring on StillOnline Free and Pro
Staging exists so you break things before customers see them. Production monitoring exists so customers never email you first. Running identical StillOnline checks on both sounds disciplined — until your phone buzzes for a deliberate staging outage at 2 a.m.
StillOnline bills by projects and URL checks per project — Free: 1 project, 1 check; Pro: 10 projects, 10 checks each. This guide helps indie teams decide what to register where.
Quick answer
Monitor production first — canonical customer health URL, status page, owner alerts. Add staging only if it has a stable public URL you care about overnight (e.g. demo for sales) and you can tolerate separate alerts. Use separate StillOnline projects for staging vs prod to avoid mixing status pages. Free cannot cover both unless you skip staging entirely. Mute staging by disabling the check or using a different owner email — StillOnline has no schedule-based mute in v1.
Comparison table
| Approach | Pros | Cons |
|---|---|---|
| Prod only (recommended pre-PMF) | One alert stream; clear customer signal | Staging breaks silently |
| Staging + prod (Pro) | Catches bad deploys early | Alert fatigue if staging unstable |
| Staging in CI only | No overnight pages | No external history |
| Same project, two checks | One dashboard | Status page mixes environments — avoid |
Plan math (2026 pricing)
| Tier | Projects | Checks / project | Typical indie split |
|---|---|---|---|
| Free | 1 | 1 | Production only |
| Pro ($9/mo) | 10 | 10 | Project A prod, Project B staging |
| Ultimate | 100 | 25 | Per-client or per-env |
Retention: 24 h history on Free, 90 days on paid — staging history is rarely compliance-critical.
Recommended setup
Solo founder, one staging URL
- StillOnline project “Production” —
api.product.com/health, public status page, Telegram. - Skip staging until you have on-call rotation or sales demos on staging.
- Use GitHub Actions smoke test after deploy to staging.
Small team with stable staging
- Project “Staging” —
staging-api.product.com/health, private status page on Pro if internal only — public vs private. - Different alert channel or disabled check during known maintenance.
- Never link staging status page in customer docs.
Alert fatigue patterns
| Mistake | Fix |
|---|---|
| Same Telegram for staging + prod | Separate bot chat or disable staging alerts |
| Staging spins down on PaaS free tier | Do not monitor sleeping preview URLs |
| Load test on staging triggers DOWN | Pause check or exclude test window manually |
Related guides
- Side-project production checklist
- Public vs private status page
- False positive tuning
- Health check quickstart
FAQ
One project with two checks for staging and prod?
Possible on Pro (two checks), but one status page mixes environments — prefer two projects.
Can I silence staging alerts at night?
Disable the staging check or route to email-only; no built-in quiet hours in v1.
Does staging need a public status page?
Usually no. Use private page on Pro for internal team or skip — private page guide.