Keep it healthy, safe and cheap
A live site needs a little care every week and a short review every month. This lesson gives you the owner's routine for Mangrove Kitchen: where to look when something breaks, how to roll back, backups, costs, key rotation, and when to call an engineer.
By the end you can
- Know where to look first when something breaks, and roll back before you fix
- Make sure a backup exists that you could restore from
- Keep a cost sheet and avoid the common free-tier traps
- Rotate a leaked key in minutes, and run a monthly security check
- Recognise the signals that it's time to call an engineer
The everyday picture
Think of owning a motorbike. Once a week you check the tyres and the oil. Once a month you look at what fuel and parking cost. You keep a spare key somewhere safe, and if you lose a key you change the lock the same day. And when the engine makes a noise you don't understand, you take it to a mechanic instead of guessing.
Your site needs the same habits: small regular checks, a spare (the backup), a fast lock change (key rotation), and knowing when to call the mechanic.
When something breaks: look, then roll back
Follow the same order every time. Stop the harm first, find the cause second.
- Did it start right after a deploy? Roll back in Vercel: open Deployments, pick the last good one and use Instant Rollback (lw-05). Then investigate calmly.
- Vercel logs. The Logs tab shows server errors with times. Free plans keep them only a short while, so look soon.
- Supabase logs. The Logs section splits API, Auth and Postgres. Sign-in problems show in Auth.
- Resend logs. Each e-mail shows delivered, bounced or marked as spam.
- Uptime monitor. A free uptime check opens your site every few minutes and alerts you when it is down, before visitors tell you.
Paste the exact error line into your agent and ask it to explain the cause before it changes anything.
Quick check
Ten minutes after a deploy, the uptime monitor reports the recipe pages returning errors. What do you do first?
The timing points at the deploy, and a rollback brings back working code in seconds. A rushed fix can break more, and restoring the database would throw away a week of real data for a code problem.