"It was a customer messaging me on LINE to say the site wouldn't load — that's how I found out." Before that message arrived, the site might have already been down all night: people opened it, saw an error page, and left; orders got submitted but never actually went through — and you had no idea any of it happened. It's not that you don't care about quality; no one has been watching that server for you in the middle of the night. The following three things are the smallest monitoring setup you need.
By the time a customer tells you, the site has usually been down for a while: maybe it went down overnight and nobody noticed until morning, or maybe a feature has been broken for three days and everyone assumed they'd clicked the wrong thing. You have no idea what happened during that gap:
What's worse is that even once you know, you don't know where to start looking: is the server down, is the code throwing errors, or is the database full? Without logs, you're just guessing. This is one of the five things covered in A Working Demo Isn't the Same as Production-Ready, and it's also the easiest one to fix first.
"Monitoring" sounds like something only big companies need. In reality, it just answers four questions:
| What it checks | The question it answers | What happens without it |
|---|---|---|
| Is it alive | Can people open it right now | It goes down overnight and no one notices until morning |
| Is it throwing errors | Is a feature actually broken | Even after a customer reports it, you can't find the cause |
| Server resources | Are disk or memory almost full | It goes down without warning on an otherwise ordinary afternoon |
| Someone receives the alert | Who sees it when something goes wrong | All three are set up, and still nobody responds |
The first three are about tools; the last one is about people. Have all four, and you'll know before your customers do. Have none of them, and you're running on luck and your customers' goodwill.
The first one is the simplest to set up: have something open your site every few minutes and notify you if it can't. The second is a bit harder, because "alive" isn't the same as "working" — the homepage might load fine while checkout does nothing when you click it.
Products built with AI tools often skip the second one, because nobody told the AI to "log errors when they happen."
The server is the computer your site runs on, and it has three things that can run out: disk space, memory, and processing power. Run out of any of them, and the site slows down before it goes down. This kind of failure is the most avoidable, because it happens gradually:
The approach is to check these three numbers regularly and act before they run out. It's the same point made in Does Your AI-Built Product Have Backups: these are all problems that "someone watching" prevents from happening.
Setting up the three monitoring pieces only solves half the problem. The other half starts after the alert goes out:
So monitoring eventually comes back to a more basic question: does this system have someone responsible for it. That's also the conclusion of The Gap Between Vibe Coding and Real System Architecture — AI can help you build the thing, but it won't take responsibility for what happens after it's built.
Monitoring isn't just buying a tool — it's finding someone willing to wake up in the middle of the night.
Who should know first when your site goes down? It should be "the person watching it" — not your customer. Nerdtechnic maintains your system as your Helper CTO, functioning like your company's technical lead without being on your payroll. The first step is a 60-minute system health check: we only need to see the code, not your production account credentials, and within 3–5 business days you'll get a one-page report you can actually understand. If your product is still relying on customers as its monitoring system, let us take a look at it as it stands today: Helper CTO: System Maintenance Plan.
Want to bring these practices into your own company?
Ask us on LINE
AI Research
Backups on an AI-built product are almost always missing, because backups were never a feature — nobody thought to ask AI to build them. This article unpacks three common misconceptions, explains why the database and uploaded files need separate backups, gives four minimum standards, and explains why it only counts as a backup once you've tested restoring it.
AI Research
A product built with AI tools is usually feature-complete but empty on the defense side, because nobody told it to lock the doors. This article uses plain-language scenarios to explain what happens with three landmines — permissions, keys, and input validation — with a five-minute three-question self-check and the order to fix them in.
AI Research
A product built with Cursor, Claude Code, or Lovable can demo well, but when it's time to hand it to real customers, you don't know what's still missing. This article lists five things most commonly missing — security, backups, monitoring, deployment, error handling — one question to ask yourself for each, a 10-minute self-check, and the order to fix them in.
Need Help?
Click here to contact us!
