Shipping changed your relationship to this app. Before, it only existed while you were looking at it; now it's out there being itself at 3 a.m., and two questions have quietly moved into your head, where they will live for as long as you run software: is it up? and is anyone using it? The first is called monitoring, the second is analytics, both are enormous professional disciplines, and — in the tradition of this entire course — you need the reading level, not the doctorate. Twenty minutes, tools you mostly already own.
Is it up? — monitoring
Start with what shipped with you. The Render dashboard is your app's vital signs: service status, deploy history, and metrics graphs — CPU, memory, request volume. You don't need to interpret those graphs deeply; you need one principle: those lines should be boring. Flat-ish, unremarkable, doing the same thing they did yesterday. The day a boring line becomes interesting — memory climbing steadily, requests spiking — is the day you go find out why, and "why is this graph suddenly interesting" is a fantastic thing to ask an agent that can read your logs.
Speaking of which: the logs remain the terminal you can't see, and the ship-day habit generalizes into a standing one — "check my Render logs; anything unhappy?" is a perfectly good thing to ask through the MCP on any given morning, the production equivalent of glancing at the dashboard on your way to the kitchen. Your request logger has been narrating out there this whole time, method-path-status, and errors in production logs are the same gift they've always been: complaints, with addresses. (The fail-loud doctrine pays its final dividend here — an app built to fail loudly writes you legible logs when something's wrong; an app full of silent catches fails into the void, and the void doesn't file tickets.)
The one gap in this picture: everything above requires you to go look. The missing piece is something that looks for you, and it exists, free, in the form of uptime checkers — services like UptimeRobot that visit your URL every few minutes and email you when it stops answering. A robot that knocks on your door around the clock and tattles the moment nobody's home. For a capstone this is optional-verging-on-fun; file the concept, because for anything people rely on, it's the difference between you telling your users it's down and your users telling you. (One free-tier wrinkle you can now predict: an uptime checker's regular visits will keep a napping free service awake more often — a side effect people sometimes use on purpose, with Render's blessing being ambiguous — so consider it another gentle argument for the coffee-a-month tier if your app has real users.)
Is anyone using it? — analytics
Analytics answers the second question, and the mechanism is smaller than its reputation: one script tag in your index.html. That tag loads a tiny script in each visitor's browser that reports the visit to a dashboard — how many people, which pages, what countries, where they came from. That's it; that's the machine.
The tool choice matters here, and I'll give you the opinionated version: use a privacy-friendly analytics service — SimpleAnalytics (the one I've personally used for nearly a decade), Umami, GoatCounter, and Plausible are the names to know, with free tiers or free self-hosting among them. They count visits without cookies, without tracking people across the internet, and without requiring you to bolt a consent banner onto your lovely app. Google Analytics exists, and choosing it for a hobby app is like a guy with nothing to haul buying a Ford F-350 — that's a massive heavy-duty pickup truck built for professional big jobs, towing and payload and fleet work — when what he does is drive to the grocery store. It's overkill: enormously capable, none of it necessary, and you won't use ninety-five percent of it unless you're doing professional-scale marketing work, which most hobby sites will simply never be. It also comes with privacy-regulation homework the light tools don't. For your capstone, the light ones aren't the compromise choice; they're the correct choice.
Here's what you get for that one script tag — this is the actual SimpleAnalytics dashboard for this course's website, meaning you're somewhere in these numbers right now (unless your ad blocker ate you, but we'll get to that):
That's the whole product: how many people, which pages, where they came from. Readable in ten seconds, everything a hobby site needs, nothing it doesn't. The install is exactly the kind of chore you delegate — "add GoatCounter analytics to this app" — and the diff will be refreshingly readable: one script tag, which you can read, and which you can then watch in action: open your own live app with dev tools up and find the little analytics request in the Network tab, dutifully reporting your visit. You built a thing that phones home, and you can see the phone call.
Two honesty notes, both of which you're equipped to understand mechanically. First: that script runs in the browser world — every visitor gets a copy, which means ad blockers can and do block it, which means your numbers undercount reality. Don't take my word for it — go watch it happen to me: open this very course's site, vibecoding.holt.courses, with your dev tools' Network tab up, and look for the request to a.holt.courses — that's my analytics tag phoning home about your visit. If you run an ad blocker, there's a decent chance you'll instead find it blocked — shown failed, or not there at all — because many blockers catch it, including mine: I literally don't count in my own analytics. Every dashboard number I've ever quoted about my own courses has been missing me, you (maybe), and everyone like us. Analytics is an estimate wearing a precise-looking dashboard; treat trends as real and exact figures as approximate. Second, the emotional calibration, because every new builder needs it: small numbers are normal, and small numbers are fine. Your app will not chart like a rocket ship, and three real users is three real people using software you made, which is three more than almost everyone ever gets. The dashboard's job is signal — did the thing you shared on Tuesday bring anyone? which page do people actually use? — not validation.
The owner's triad
Put the two halves together and you have the standing move for whenever your live app feels off — a report from a friend, a weird vibe, a hunch: check the triad. Status (is it up — dashboard), logs (what happened — MCP), analytics (who was there — dashboard). Thirty seconds, three tabs, and you've either found the thread to pull or confirmed all is well — and when there is a thread, it feeds straight into the debugging loop you already run: the logs are observations, the analytics are reproduction context, and the gap report practically writes itself. Watching a running thing isn't a new discipline bolted onto this course; it's the same reading, pointed at production.
🤖 Ask your AI Assistant. Two beats. First, the delegation: "Add [Umami/GoatCounter/Plausible] to my app" — then verify like you were taught: read the one-tag diff, deploy, visit your live app, and catch the analytics beacon in the Network tab yourself. Second, the right-sizing conversation, which is the real skill of this lesson: "Given what this app is and who uses it, propose a lightweight monitoring plan — what's worth watching, what's worth being alerted about, and what would be overkill?" Read the answer with your calibration hat on: a capstone needs a boring dashboard, a log glance, and maybe an uptime robot — and if the agent proposes an enterprise observability stack for your reading shelf, you've just found a fun opportunity to practice telling the golden retriever no.
Recap
- Monitoring answers "is it up": the Render dashboard's lines should be boring, "check my logs, anything unhappy?" through the MCP is a fine morning habit, and fail-loud apps write legible logs. Uptime checkers are the robot that tattles when nobody's home — optional today, essential when people rely on you.
- Analytics answers "is anyone using it": one readable script tag, a dashboard of visits. Use the privacy-friendly ones (SimpleAnalytics, Umami, GoatCounter, Plausible) — no cookies, no consent-banner homework — and skip the F-350 you'd never use for groceries.
- The numbers undercount (ad blockers, browser world — you know exactly why) and small numbers are fine: three real users is three real users. Trends over figures, signal over validation.
- The owner's triad for when things feel off: status, logs, analytics — thirty seconds, then the debugging loop you already know.
Next: the victory lap.
