Verification
Confirm your uptime monitoring is fully configured and test that alerts actually fire before relying on them.
You've set up monitors and alert contacts. But "set up" is not the same as "working." The only way to know your alert system works is to test it — deliberately trigger a downtime condition and confirm you receive the alert.
This is the same discipline a CA applies when testing a control: you don't just set up the control, you test that it catches what it's supposed to catch. An untested monitoring system gives false confidence.
Setup Checklist
Work through this before testing. Every item must be ticked before the test is valid.
- UptimeRobot account created and email verified
- Monitor created for your production app URL (e.g.,
https://edutrack.vercel.app) - Monitor created for your Supabase API URL (
https://[ref].supabase.co/rest/v1/) - Both monitors showing green (Up) status in the dashboard
- Alert contact created with a real, regularly-checked email address
- Alert contact email verified (check for the UptimeRobot verification email)
- Alert contact attached to the production app monitor
- Alert contact attached to the Supabase API monitor
- Status page created and accessible at
stats.uptimerobot.com/[your-key] - Status page shows both monitors with current status
- Status page URL shared with or noted for your client
If any item is unticked, complete it before proceeding to the test. A test run with an unticked item will not give you a reliable result.
The Alert Test
This test confirms that a downtime condition actually triggers an email to your inbox.
This test briefly takes your app down. Only run it during a low-traffic period — not during business hours if your app already has real users. For a training app with no real users yet, any time is fine.
Method 1 — Return a 500 Error from Vercel (Recommended)
The cleanest test is to temporarily break your production deployment and then fix it.
Create a temporary break in your code
In your project's main entry file (for a Vite React app, src/main.tsx), add this at the very top, before any imports:
This causes the app to crash immediately on load, which Vite's production build will turn into a 500-class error on Vercel.
Commit and push to trigger a Vercel deploy
Wait for Vercel to deploy
Watch the Vercel dashboard. The deploy takes 60–90 seconds. When it completes, the production URL will return an error.
Verify the error yourself
Open your production URL in a browser. You should see an error page — either a blank page, an error message, or a Vercel error screen. This confirms the break is live.
Wait for the UptimeRobot alert
UptimeRobot checks every 5 minutes. It requires 2 consecutive failed checks before sending an alert. Maximum wait: 10 minutes from when the broken deploy went live.
Check your email. You should receive:
Fix the code immediately
Remove the throw statement you added:
Commit and push:
Wait for the recovery alert
After Vercel deploys the fix (60–90 seconds) and UptimeRobot confirms the app is back up (up to 5 minutes), you receive:
If you received both emails — the downtime alert and the recovery alert — your monitoring is working correctly.
Method 2 — Temporarily Pause Vercel (Simpler but Less Realistic)
If you don't want to modify code, you can temporarily pause your Vercel project:
- Vercel dashboard → your project → Settings → General → scroll to bottom → "Pause Project"
- The project stops serving requests — your URL will return a 404 or timeout
- Wait for UptimeRobot to detect it and send the downtime email
- Vercel dashboard → "Unpause Project"
- Wait for the recovery email
This method tests the alert system without touching your code. The downside is it's a less realistic failure scenario — a real outage usually comes from a broken deploy, not a manual pause.
What a Passing Test Looks Like
| Check | Expected |
|---|---|
| Downtime email received | Within 10 minutes of the break going live |
| Email subject line | [UptimeRobot] [Monitor Name] is DOWN |
| Email body includes the error reason | HTTP 500 or timeout |
| Email body includes the timestamp | Should match when you pushed the breaking commit |
| Recovery email received | Within 10 minutes of the fix going live |
| Status page showed red during the outage | Yes (check your browser history or refresh during the test) |
| Status page shows green now | Yes |
| UptimeRobot dashboard shows the incident | Yes — click the monitor → "Response Times" to see the gap |
If the Alert Did Not Arrive
Work through these in order:
1. Check your spam folder first. UptimeRobot emails frequently land in spam, especially for new accounts. If the downtime email is there, mark it as "not spam" and add UptimeRobot's sending address to your contacts.
2. Confirm the alert contact is verified. Go to My Settings → Alert Contacts. The contact should show as active (not "unverified"). If it shows unverified, resend the verification email and confirm it.
3. Confirm the alert contact is attached to the monitor. Click the monitor → Edit → scroll to "Alert Contacts to Notify" — your contact should have a checkmark. If not, add it and save.
4. Confirm the monitor actually detected the outage. Click the monitor in the UptimeRobot dashboard. The status should have gone red during your test window. If it stayed green, the monitor didn't detect your break — likely because the URL you're monitoring is different from the one that was broken (check for www vs non-www, or http vs https).
5. Wait longer. On the free plan, checks happen every 5 minutes and require 2 consecutive failures. Maximum detection time is 10 minutes. If you only waited 5 minutes, wait another 5.
Ongoing Maintenance
Uptime monitoring is not a one-time setup. As your project grows, revisit it:
| Trigger | Action |
|---|---|
| New environment variable added | Confirm the app still loads correctly after deploy — monitoring catches deploy failures |
| New team member joins | Add them as an additional alert contact |
| App goes to production with real users | Consider upgrading to 1-minute check intervals (paid plan) |
| Client asks "can I see the status page?" | Share the stats.uptimerobot.com/[key] URL |
| App adds a new critical endpoint (e.g., payment API) | Add a dedicated monitor for that endpoint |
| Free Supabase tier approaching limits | Pre-emptively upgrade before the project pauses — monitoring alone can't prevent this |
You're Done
Your uptime monitoring infrastructure is complete and verified:
- Two monitors running 24/7
- Email alerts firing within 10 minutes of any downtime
- A public status page your clients can bookmark
- A confirmed test proving the alert pipeline actually works
From this point, uptime monitoring runs silently in the background. The next time something goes wrong with your app, you'll know about it before your clients do.