In this guide
When you run a product alone, you're also the operations team. You won't have someone watching dashboards at 3 a.m., and you shouldn't need to. You need a few alerts that wake you only for real problems, backups you've actually restored once, and a short weekly look at the numbers.
The four things to monitor
| What | Question it answers | How |
|---|---|---|
| Uptime | Can people reach the site and sign in? | An external check on the home page and a sign-in endpoint every few minutes |
| Errors | Is something failing for some users? | Error reporting in the front end and in functions |
| Usage vs limits | Will a plan pause or cap us soon? | Alerts in each provider's dashboard |
| Jobs | Did the scheduled work actually run? | A "last run" timestamp you check, or a heartbeat ping |
Uptime: check from the outside
Your host's status page tells you whether the host is up, not whether your product works. Use an external uptime checker that loads your site from several locations and alerts you when it fails. Check two things: the home page, and something that touches the database, such as a lightweight health endpoint.
Keep alerts to things that need you now. An alert that fires every day for nothing trains you to ignore the one that matters.
Errors: hear about them first
Add an error-reporting tool to the front end and to your functions, so exceptions are collected with the page, browser and user involved. Then:
- Alert on new error types, not on every occurrence.
- Look for errors on sign-in and payment pages first. Those cost you customers fastest.
- Tag errors by deploy, so you know which change introduced them. If a deploy broke something, roll back first; see previews and rollbacks.
Usage against limits
Many small-product outages aren't bugs: a plan ran out. Hard limits can pause a site; on Netlify's credit plans, a site that reaches its monthly limit pauses until the next billing cycle, and auto-recharge is off by default[3]. Usage-based plans keep running but bill more; Vercel's Pro plan includes spend management for that[5].
Set these once
- Hosting usage alerts at 50% and 80%.
- Email-sending alerts near your daily and monthly limits.
- Database size and egress alerts.
- A spending cap on anything billed per use (AI, text messages).
Jobs that should have run
Scheduled jobs fail silently: if a weekly reminder job doesn't run, nothing errors; the reminders just don't go out. On Netlify, scheduled functions also only run on published deploys, not previews[4], which is easy to forget when testing.
Two simple patterns:
- Last-run timestamp: each job writes when it last finished. A daily check alerts you if it's older than expected.
- Heartbeat: each job pings a monitoring service when it completes. No ping in time, you get an alert.
Backups: what and how often
Your code is already backed up in Git. Your database isn't, unless you or your provider do it. On Supabase, Pro, Team and Enterprise projects are backed up daily, with Pro keeping the last seven days[1]; the documentation doesn't list automatic backups for free projects and recommends exporting data regularly with the command-line tool[1]. Pro starts at $25 a month[2].
| Data | Backed up by | Your job |
|---|---|---|
| Code | Git and your host's deploy history | Commit often |
| Database | Your provider on paid plans, or your own exports | Confirm schedule; test a restore |
| Uploaded files | Depends on your storage service | Check whether they're included |
| Settings and secrets | Nobody, by default | Keep a private, up-to-date record |
Restore once, on purpose
A backup you've never restored is a hope. Once, on a quiet day:
- Create a separate test project.
- Restore last night's backup into it.
- Check that the tables, row counts and a few real records look right.
- Write down how long it took and what you had to look up.
That note becomes your recovery plan. When something goes wrong at a bad moment, you'll follow steps instead of searching documentation.
A fifteen-minute weekly routine
Every Monday
- Any new error types? Fix or file them.
- Usage on each provider: anything above 60% of its limit?
- Did every scheduled job run every time it should have?
- Last database backup: present and recent?
- Failed payments and cancellations: anything unusual? See early cancellations.
When something does break
Hypothetical example
9:40 p.m.: your uptime check alerts that sign-in is failing. A calm sequence:
- Confirm: try signing in yourself, from a private window.
- Check recent changes: was there a deploy in the last few hours? If so, roll back first.
- Check providers: look at your login service's and database's status pages and your usage dashboards. A paused plan looks exactly like a bug.
- Tell customers if it lasts: a one-line note on your status page or by email beats silence.
- Write it down afterwards: what happened, how you found out, what would have caught it sooner.
That last step is how your monitoring gets better: every incident adds one check that would have caught it.
A simple status page
For a small product, a status page can be a single static page you update by hand during an incident, linked from your app's footer and support email. Customers mostly want to know that you know, and roughly when it'll be fixed.
Gaps people find too late
- Relying on customers as monitoring. Most won't write; they'll leave.
- Too many alerts, so the real one gets ignored.
- Customer data on a plan without backups.
- Never testing a restore.
Today: add an external uptime check on your home page and sign-in, and set usage alerts on your host. This week: restore your database once into a test project.
Sources
Checked 14 November 2026. Numbers in brackets in the text point to these sources.
