Running a production application as a solo developer is a particular kind of responsibility. You are simultaneously the product manager, the support team, the on-call engineer, and the person who has to fix things at 3am when your payment webhook goes silent.
Downtime is expensive in multiple ways. Direct revenue loss. Customer trust damage. Support burden. Reputation in communities where word travels fast. And the personal cost — the stress of finding out your app was broken for two hours because a customer emailed you.
This guide covers what to monitor, how to set up alerting that actually works for a one-person operation, and how to get the most out of Vigilmon's free tier when you're watching the bottom line.
The Solo Developer Reality
You have no on-call rotation. When something breaks, it breaks for you until you fix it — regardless of the time or day. That creates specific requirements for how monitoring should work:
You need to know fast. A 5-minute check interval means a failure that happens at minute 1 goes undetected for up to 5 minutes. For a payment-processing SaaS, that's potentially 5 minutes of failed transactions before anyone knows. 1-minute intervals are the minimum for production.
You need accurate alerts. A false alert at 2am — one that wakes you up for a 30-second network blip that resolved itself — costs you sleep, focus, and trust in your own tooling. After enough false alerts, you stop treating alerts seriously. That's when the real outages go unnoticed.
You can't monitor everything. With limited monitor slots (especially on a free tier), you need to prioritise ruthlessly. Monitor the things that, if broken, directly damage customers or revenue. Everything else can wait for morning.
You need simple escalation paths. When something breaks, you need to know immediately. Your alerting needs to reach you wherever you are — phone, laptop, Slack, email.
What to Monitor First
The Core Product
Whatever your application does for its paying customers, that core path should be monitored. If you have a dashboard that users log into, monitor the dashboard URL. If you have an API that clients call, monitor the main API endpoint. If your product is a Chrome extension with a backend, monitor the backend health check.
A monitor on your main domain is the minimum. Better is a monitor on a representative endpoint that exercises your actual application stack — one that requires a database round-trip and returns a meaningful response.
Authentication
If users can't log in, they can't use your product. A broken auth endpoint is functionally equivalent to a full outage, even if every other part of your app is working. Monitor your login endpoint and confirm it returns a 200.
Payment Webhook Receiver
If you charge customers through Stripe, Paddle, or another payment processor, you have a webhook endpoint that receives payment events. Subscription renewals, failed payments, and refunds all flow through it. If that endpoint returns a 500 or times out, your payment processor will retry — but if you miss too many, you'll have payments that don't register, subscriptions that don't renew, and customers who aren't properly activated.
This endpoint deserves its own dedicated monitor. It should return a 200 to the monitoring ping; the actual webhook handling only processes authenticated payloads.
Email Delivery
If your product sends transactional emails — welcome emails, password resets, notifications — and your email provider goes down or your sending domain gets blocked, your users can't reset passwords or activate accounts. Monitor your email sending by either checking a health endpoint on your email service integration or by using a heartbeat that confirms your email queue is being processed.
SSL Certificate
A certificate expiry takes your site offline for all users simultaneously and requires an immediate fix under pressure. SSL certificate monitoring with a 30-day warning gives you plenty of time to renew without urgency. This is one of the highest-value, lowest-effort monitors you can add.
What Can Wait
Not everything needs to be monitored at 1-minute intervals. Some things can be checked less frequently or addressed reactively:
Internal admin tools — If your admin dashboard breaks, you'll notice when you try to use it. It's not customer-facing.
Blog or marketing pages — These are worth monitoring eventually, but they don't affect active users' ability to use the product.
Static assets and CDN — Worth adding once you've covered the above. CDN failures are usually brief and self-correcting.
Database metrics — Infrastructure-level database monitoring (query times, connection count) is valuable as you scale. For a solo developer with one production database, it's secondary to external endpoint monitoring.
The principle: if a customer would be blocked from using your core product, monitor it. If a problem would only affect you internally, it can wait.
Setting Up Alerting That Works Without Burning You Out
Use Multiple Channels, But Choose Them Deliberately
For a solo developer, the right alerting setup is usually:
- Email for non-urgent alerts (certificate expiry warnings, recovery notifications)
- Slack or phone for immediate failure alerts
If you have a Slack workspace you check constantly, a Slack alert for failures will reach you faster than email. If you need to be woken up, push notifications via a mobile app or phone call are more reliable than Slack.
Set Alert Channels Based on Severity
Not all failures are equal. An SSL expiry warning 30 days out is not the same as your payment webhook returning 500s right now. If your monitoring tool allows it, route critical failures to immediate channels and warning-level alerts to email.
Require Confirmation Before Alerting
Single-probe monitoring tools fire alerts the moment one check fails. That includes transient DNS failures, brief network issues, and probe-side anomalies. These generate false alerts.
Vigilmon requires multiple geographically distributed probes to independently confirm a failure before sending an alert. This means that when you do get paged, something is actually wrong. For a solo developer who needs every alert to be actionable, this consensus-based approach is the correct default.
Set a Recovery Alert Too
Knowing your site came back up is almost as important as knowing it went down. Recovery alerts tell you the incident is over so you can stop monitoring manually and know what the actual downtime window was.
Maximising Vigilmon's Free Tier
Vigilmon's free tier includes 5 monitors at 1-minute intervals. Here's how to allocate them for maximum coverage:
- Primary application URL — your main domain or app subdomain
- Core API endpoint — the endpoint that exercises your database and business logic
- Payment webhook — your Stripe/Paddle webhook receiver
- SSL certificate expiry — your main domain's cert
- Scheduled job heartbeat — if you have a critical background job (billing, notifications, data processing)
This covers the five highest-risk failure modes for most solo SaaS products. If you have multiple critical endpoints, upgrade to a paid tier — the cost is typically less than the revenue lost in a single undetected outage.
The Setup (Under 10 Minutes)
1. Create a Vigilmon account at vigilmon.online. No credit card required.
2. Add your primary URL as a monitor. Set expected response code to 200. Leave the interval at 1 minute.
3. Add your auth endpoint and payment webhook endpoint as separate monitors.
4. Add an SSL monitor for your main domain.
5. For any critical cron jobs or background workers, copy the heartbeat URL from Vigilmon and have your job hit it on successful completion.
6. Configure alert channels: add your email address and connect Slack if you use it.
7. Set up a status page (takes 2 minutes) so users have somewhere to check during incidents instead of flooding your inbox.
The 3am Calculation
Every solo developer eventually does the 3am calculation: is the monitoring I have worth the cost of the alternative?
The alternative is finding out your app was broken for three hours because a customer emailed you at 9am. The alternative is discovering your payment webhook silently failed for two days during a busy weekend. The alternative is your SSL certificate expiring at midnight on a Friday.
Monitoring doesn't prevent these failures. It compresses the time between failure and fix — from hours (or days) to minutes.
For a solo developer, that compression is the difference between a minor incident and a customer trust crisis.
Set up monitoring for your solo project at vigilmon.online — 5 monitors, 1-minute intervals, free forever.