When you run a product alone, nobody is on call except you. There's no ops team, no pager rotation, no colleague who notices the dashboard is red. Most solo developers find out their app is down the worst possible way: a user emails "is it just me?", or worse, they just leave.
Uptime monitoring fixes that, and it doesn't need to be complicated. You don't need a full observability platform to answer one question: is my app answering, and is it answering correctly? This post covers what a useful uptime check looks like for a small product, how to avoid alert fatigue, and how it works in Pullwish.
What an uptime check should actually test
A lot of "monitoring" stops at "did the server respond". That catches a dead server, but it misses the failures that actually hit indie apps: a deploy that serves a blank error page with a 200, a login page that loads while the API behind it is broken, or a CDN that returns something that isn't your app at all.
A useful check tests three things:
The status code you expect. Usually 200, but if you monitor a health endpoint or a redirecting URL, you should be able to say exactly which code counts as healthy.
That the right content is there. A keyword check reads the response body and confirms a string you know should be present, like your app name or
"ok"from a health endpoint. If the keyword is missing, the check fails, even with a 200.That it answers in reasonable time. A site that takes 40 seconds to load is down as far as your users are concerned. A timeout turns "slow" into a failure you hear about.
In Pullwish, each monitored site has a URL, an expected status code, an optional keyword, and a timeout of 5, 10 or 30 seconds. Without a keyword, the check sends a lightweight HEAD request and falls back to GET if the server doesn't allow HEAD. With a keyword, it always uses GET, because it needs the body.
One practical tip: point the check at a page or endpoint that exercises your real stack. If your homepage is static and cached at the edge, it will happily stay "up" while your database is down. A small health route that touches the database, combined with a keyword check, tells you much more.
Don't wake up for a blip
The fastest way to make monitoring useless is to make it noisy. If every single network hiccup sends you an email, you'll start ignoring them, and then you'll ignore the real one too.
That's why each site has a failure threshold: how many failed checks in a row it takes before you're alerted. The default is 2, and you can set it anywhere from 1 to 10. One failed check marks the site as down in the dashboard, but the alert only goes out when the threshold is reached.
The same logic applies on the way back. You get a "recovered" alert only if a "down" alert was actually sent. A single blip that never crossed the threshold doesn't produce a confusing "recovered" message about an outage you never heard about.
For most solo projects, 2 is a good starting point. If you monitor something flaky that you don't control, raise it. If it's your checkout or login, keep it low.
Where the alerts go
When a site crosses the threshold, Pullwish:
emails the project's notification addresses, or the project members if you haven't set any,
sends a request to the site's own webhook URL, if you've added one (and you can send a test webhook from the form before saving),
fires the project-level webhook events
monitoring.downandmonitoring.recovered.
The webhooks are the useful part if you already live in another tool. Point them at a small endpoint that posts to your chat, creates an issue, or triggers whatever you use. The events and their payloads are in the webhooks docs.
How often to check
Checks run on a schedule, and how often depends on your plan: every 60 minutes on Indie, every 30 minutes on Startup, and every 15 minutes on Business. You can choose a slower interval for a site if you want, but not faster than your plan's minimum. Uptime monitoring isn't included on the free Hobby plan.
This isn't second-by-second monitoring. If a two-minute outage costs you real money, use a dedicated service with one-minute checks. For a typical indie SaaS or side project, knowing within 15 to 60 minutes, with a confirmation check first, solves the problem that actually hurts: being down all night without knowing.
A public status page, included with monitoring
Once your sites are monitored, the project gets a public status page. It shows an overall state (all systems operational, partial disruption, or major outage), each monitored service with its current status and uptime, any active incidents, and your latest published changelog entries.
A status page users can check means fewer "is it down?" emails, and the changelog next to it shows the product is looked after. If you also want to tell users about planned downtime, pair this with maintenance mode and status banners.
Why keep it in the same tool
When a site goes down, the next questions are always: did I just deploy, are errors spiking, are users complaining? In Pullwish, uptime, error tracking, feedback and the changelog live in the same project, so you look in one place instead of four.
The checks also have one safety rule worth knowing: monitored URLs must be publicly reachable. Internal addresses and cloud metadata endpoints are blocked, so the monitor can't be pointed at your private infrastructure.
A five-minute setup
Add a small health route to your app that touches your database and returns a known string.
In your Pullwish project, open Monitoring and add the URL.
Set the expected status code, add the string as the keyword, and pick a timeout.
Leave the failure threshold at 2 to start.
Optionally add a webhook URL and send a test.
Share the status page link in your app's footer or help page.
That's it. The next time something breaks at 3 a.m., you'll hear about it from your monitor, usually before your users do.
If you want to try it, create a Pullwish account. New accounts get Indie free for 14 days, no card required, and you're only charged if you choose a paid plan.
AI Disclaimer: This article was drafted with AI assistance from my own notes on how I use Pullwish. I reviewed, edited and fact-checked it against the product before publishing.