Production monitoring checklist for a side-project SaaS
You do not need a Datadog bill to leave “works on my laptop.” You need a short list you can finish in one evening: something the internet can probe, a page customers can bookmark, and one alert that reaches your phone when the probe fails.
This checklist is for indie founders shipping a micro-SaaS, API, or no-code backend on Vercel, Railway, or similar. StillOnline covers the minimum layer: external HTTP checks, a hosted public status page, and owner alerts through email, the StillOnline Telegram bot, or Slack. You can skip self-hosted Uptime Kuma and a full observability stack on day one.
Quick answer
Before you call a side project “in production,” ship four things: a public GET health URL that returns HTTP 200, an external uptime check on that URL, a public status page link in docs, and one owner alert channel (email, Telegram via the StillOnline bot, or Slack). StillOnline Free covers that with one project, one URL, 5-minute probes, 24-hour history, and stillonline.tech/s/...—see health URL quickstart. Add Telegram alerts the same day; upgrade to Pro ($9/mo) when you need a second URL or a private page.
When “side project” becomes production
“Production” here does not mean SOC 2. It means someone else depends on your URL: a beta user, a Stripe subscriber, or an API key in a client’s script. You need to know you are down before they open a support ticket.
| Signal | Why monitoring moves up |
|---|---|
| First external user or API key | Outages are invisible in your local logs |
| Money on the table (even $20/mo) | “Is it down?” emails cost more than monitoring |
| You sleep while cron or webhooks run | You will not notice a 3 a.m. deploy failure |
You still skip enterprise APM until revenue or compliance forces it—status page without full observability explains the middle path.
The checklist (do in order)
Work top to bottom once. Each step unlocks the next; skipping the health URL makes every later step guesswork.
1 — Define what “down” means
Pick the single HTTPS URL that means “customers cannot use the product.” For many stacks that is GET /api/health on the API host, not the marketing homepage alone. API-only products: what to monitor.
Write the path in README and your runbook. Monitors—including StillOnline—only see status code on the URL you paste, not your intentions.
2 — Ship and verify the health URL
Implement a fast handler (under ~2 seconds), return 200 when the app is usable, and curl from outside your Wi‑Fi before you register anything. Full steps: health check URL quickstart.
Common mistakes at this step:
- Health route behind auth → monitors see 401 and mark you down.
- Redirect chains → some tools stop at the wrong code; fix to a single 200 URL.
- Readiness that pings the DB on every request → noisy “down” during brief DB blips (choose liveness vs readiness on purpose).
3 — Register an external check
Local docker compose up does not prove the world can reach you. Register the full HTTPS URL in StillOnline:
- Start free → New project → public status slug.
- Add check → GET, expect 200, interval 5 min on Free.
- Wait 2–3 probe cycles before judging red vs green.
Free: 1 project, 1 URL, 24h history. Second critical URL or private status page → Pro.
4 — Publish the status page link early
Create the habit before the first incident: put https://stillonline.tech/s/{project-id} in onboarding, Notion, or your support macro. Walkthrough: public status page for SaaS.
During deploys, use scheduled maintenance instead of silence. After an outage, use the incident post template. Link the status page first.
5 — Turn on owner alerts (one channel on Free)
In account settings, enable one channel on Free: email, Telegram (Connect Telegram → StillOnline bot → Start—no BotFather), or Slack Incoming Webhook. Setup guides: Telegram · Slack.
Pro / Ultimate enable all three owner channels. Public Subscribe with Google on the status page is separate: it emails subscribers on incident updates. It does not replace an alert on your phone.
6 — Optional: Page Speed and MCP (when it hurts)
- Core Web Vitals / Lighthouse — separate concern from uptime; link Page Speed monitoring on StillOnline when marketing performance matters, not a second PSI-only blog post.
- MCP in Cursor — after infra churn on Pro, recreate checks from the IDE (MCP guide).
What to skip on day one
| Temptation | Skip because |
|---|---|
| Full Datadog / Grafana stack | Cost and setup time beat a side project’s runway |
| Self-hosted Uptime Kuma | Ops tax before you have revenue — hosted alternative |
| Monitoring every microservice | One “product down” URL first |
| Native Discord webhook in StillOnline | Not shipped in v1 — workarounds if you need Discord |
| Custom domain on the status page | StillOnline hosts at stillonline.tech/.../s/... — share that link |
Tool shopping? Best uptime monitoring for indie SaaS 2026 · StillOnline vs alternatives.
Weekly five-minute habit
Production monitoring rots when URLs move without updating checks.
- Glance at the status page after deploys. It should go green after 2–3 intervals.
- After domain or path changes, update the StillOnline check URL the same PR.
- Once a quarter, open the public page in a private window. Confirm it loads and shows recent history.
When the checklist is done and you get first revenue, read status page when SaaS gets first paying users for the support and upgrade signals.
Related guides
- Health check URL — 5-minute quickstart
- Public status page for SaaS, API, or bot
- Telegram owner alerts (StillOnline bot)
- Status page at first revenue
FAQ
Does StillOnline replace logging and APM for a side project?
No. StillOnline answers “did this URL return the expected HTTP status on a schedule?” and hosts a status page with short history on Free. Logs, traces, and error tracking stay in your host or a future APM tool—status page without full observability. Start with one health URL, then add depth when outages repeat in the same subsystem.
Is StillOnline Free enough before my side project has paying users?
Usually yes. Free includes one external check, a public page, and one owner alert channel—enough to learn your failure modes before MRR. When you need a second URL (API + marketing), private status, or API/MCP automation, move to Pro. Revenue-specific playbook: first paying users.
Should StillOnline monitor my Vercel preview URL or production?
Can I run this checklist without a public status page?
You can run checks and owner alerts only, but you lose the link customers and partners bookmark. StillOnline Free includes a public page at stillonline.tech/s/...—use it in docs before the first outage. Private pages are a Pro toggle when you need an internal view.
Telegram or email for StillOnline alerts on a nights-and-weekends side project?
Telegram via the StillOnline bot reaches your phone on every failed interval while a check is down. That suits solo founders. Email throttles repeats (about once per 15 minutes) and works well as an archive. On Free pick one channel in settings; Pro enables all three.
Does StillOnline check SSL certificate expiry on Free?
Not as a dedicated SSL monitor on Free. Your HTTP check may fail if TLS is broken, but expiry warnings need registrar reminders or a separate SSL tool. Focus the first evening on a stable 200 health URL and owner alerts—see health endpoint design if you split liveness and readiness.