You can describe an app in plain English, watch Claude or an AI coding tool scaffold it, deploy it that afternoon, and have paying users by the weekend. That part of building software has gotten radically faster. What hasn't changed: the app still goes down, certs still expire, cron jobs still fail silently, and none of that gets fixed by the same prompt that built the thing in the first place.

In early 2025, Y Combinator's CEO said about a quarter of that batch's startups had codebases that were roughly 95% AI-generated. "Vibe coding," building software by describing what you want and letting AI write it, went from Andrej Karpathy's February 2025 coinage to Collins Dictionary's Word of the Year by that November. The tooling is real and it works. The habits that used to come bundled with "I hand-wrote every line and understand what's running" didn't come with it.

The gap nobody warns you about

No AI coding tool watches your production environment after it ships the code. That's not a criticism of the tools. It was never their job. But it means the responsibility for knowing when something breaks lands on you, at the exact moment you have the least experience carrying it. A lot of people vibe coding today are shipping their first real production app, full stop. They've never had a cert expire on them at 2am. They don't yet have the reflex to ask "what happens when this endpoint times out" or "who finds out first when the database connection pool fills up."

That gap is already showing up in ways that are hard to miss:

  • A May 2026 scan by security firm RedAccess checked 380,000 publicly accessible apps built with tools like Lovable, Replit, and Base44, and found roughly 5,000 of them leaking sensitive data. About 40% of the exposed apps were leaking things like medical records, financial data, or internal business documents, not because the AI wrote bad logic, but because default privacy settings shipped public and nobody was watching to notice.
  • Veracode's GenAI Code Security Report tested output from 100+ AI models across common coding tasks and found 45% of the generated code contained OWASP Top 10 vulnerabilities, with cross-site scripting and log injection flaws each showing up in the majority of relevant samples. The finding that stands out: making the model bigger didn't reduce the failure rate. This is closer to a systemic pattern than a bug in any one tool.
  • On the infrastructure side, AI-assisted changes have been linked to real production outages over the past year, including incidents where an AI coding agent altered or deleted live production data. The pattern reported across several of these cases is the same: the change looked reasonable to the tool making it, ran in production, and nobody had monitoring in place to catch the damage before it compounded.

None of this means AI-generated code is uniquely bad. It means the apps built with it are, on average, going into production with less scrutiny and less monitoring than software built the slower way, because the slow way used to force a lot of "wait, how do we know if this breaks" conversations that vibe coding skips by default.

How most vibe coders actually find out something's down

Ask around and the honest answer is: a user tells them. A DM, a tweet, a support email that starts with "hey is your site down?" By the time that message arrives, the outage has already been running for however long it takes someone to notice, get annoyed, and type it out. For a side project that's embarrassing. For anything with paying users, it's lost revenue and a trust hit you don't get to undo.

The fix isn't complicated, it's just not automatic. You need something external to your app watching it, because the app can't reliably tell you it's down. That's the whole problem with self-reported health checks. You need SSL and domain expiry tracked separately from uptime, because those fail silently and on their own schedule, usually a renewal cycle nobody remembers signing up for. And if any part of your stack runs on a schedule (a cron job, a queue worker, a nightly sync), you need something watching for the job that should have run and didn't, which is a different problem than watching for a page that's slow to load.

What this looks like for an AI-built app specifically

A few habits translate directly from "how agencies monitor 50 client sites" to "how one founder monitors the thing they shipped last week":

Uptime and SSL on the URL, from day one. This is the baseline every app needs regardless of how it was built. Add the monitor when you add the domain, not after the first outage.

Heartbeat monitoring for anything that runs on a schedule. If a background job, cron task, or scheduled sync stops running, you won't get an error. You'll just get silence, and silence doesn't page anyone by default. A heartbeat monitor expects a check-in on a schedule and alerts you the moment one doesn't arrive.

API monitoring with actual assertions, not just a status code. A broken endpoint can still return 200 OK while returning the wrong data, an empty payload, or a stale cache. Checking for the response you actually expect (a field present, a value in range) catches failures a plain uptime check waves through.

A monitoring setup you can talk to instead of another dashboard to check. If you're already living inside an AI coding workflow, the natural interface for "is anything broken" is asking, not logging into one more tool. An MCP server that exposes your monitors to Claude or another AI assistant means you can ask "did any of my scheduled jobs fail last night" or "which of my domains have certs expiring this month" in the same place you're already working.

None of this requires an ops background. It requires deciding, once, that the app you shipped in an afternoon deserves the same "how would I know if this breaks" question you'd ask about anything else you're responsible for.

Where Sentinel fits

Sentinel covers uptime, SSL, DNS, and domain-expiry monitoring on every endpoint you add, plus heartbeat monitoring for cron jobs and background workers, and API monitoring with JSON assertions for endpoints that need more than a status-code check. The free plan is 10 monitors with 5-minute checks and a public status page, no card required and no commercial-use restriction, which covers a typical solo project or small indie portfolio outright. Paid plans add the MCP server, so you can ask Claude directly what's up, what's down, and what certs are about to expire instead of checking a dashboard.

If you're shipping fast with AI tools, the code getting written quickly isn't the risk. Nobody watching it once it's live is. Add monitoring before the first outage, not after. Set it up in a few minutes at sentinel.rootstuff.io.