Watch an AI-built app after launch (2026)

Who this is for

You shipped from Lovable, Bolt, Replit, Cursor, or another AI builder. A live host answers. People who are not you can create an account. Money can move, or it will soon. You want the first mail about a break to land in a company inbox, not in a one-star review.

You are not this page if the app still lives only on a laptop, if only the founder can log in, or if you cannot take the live URL down tonight. Those are harden and people jobs. Open the production-ready page for the operating contract. Open hire a developer for an AI-built app if the people list is blank. Open GitHub handoff after an AI builder if the repo still sits on a personal login.

You are also not this page if you only want a prettier dashboard. A chart you open on Monday is not a watch. A watch wakes one person while the break is still small.

What “watch” means

Watch is six signals you can name on one card. If any signal has no clock and no owner, you are hoping. Customers will tell you. That is late.

• The public page answers. A robot hits the live URL on a clock. That is uptime: whether the site is up.
• The app does not crash in silence. A crash list groups the same break and can mail you.
• Sign-up and login fail in the open. A stranger can create a seat. A stranger can come back.
• Payment messages arrive. A webhook is a signed note your payment company sends to your app when money moves.
• Pages stay fast enough to use. A page can answer and still be too slow.
• One named owner hears the mail. That person can halt the host tonight. A backup is named.

Uptime: the public page is up

Uptime means the public page answers when a machine asks. A founder refresh on one phone is not a check. A check is a robot that hits the live URL on a clock and mails you when the answer is not a success.

UptimeRobot’s free plan gives you 50 monitors and a 5-minute check. The free-plan help page (updated 28 September 2026) says that plan is free for commercial use and does not need a card. That is enough to watch a homepage, a sign-in page, and a simple health URL. Better Stack checks as often as every 3 minutes on a free plan, and every 30 seconds on a paid plan.

Better Stack’s start guide says an HTTP status monitor looks for a success answer — a code in the 200s. If the URL does not return that, the monitor opens an incident and alerts the person on call. Put the same idea on your stack even if you pick a cheaper clock. The click that matters is “mail one person when this URL fails.”

Check more than the homepage. A home page can stay up while `/login` returns an error. A keyword check asks the page to contain a word you expect, not only “the server answered.” If the live host still shows a builder error shell, a bare success code will lie to you.

Write the live origin you will keep. A leftover builder preview is not that origin. Testers bookmark it. Later you change the name. The clock still hits the old host. You think you are watched. You are watching a lab.

Crashes: a list, not a store tab

A crash list is a reporter on the live build. It groups the same break, names who it hit, and can mail you when it grows. Firebase Crashlytics is a realtime crash reporter for Apple, Android, Flutter, and Unity. A week with no reporter is a week you cannot describe.

Crashlytics alerts can mail you for new fatal issues, new non-fatal issues, old issues that come back, trending issues, and increasing-velocity issues. New fatals are not sent unless you turn them on. Turn them on. Velocity alerts fire when one issue crosses a share of sessions and a minimum user count in a 30-minute window. The default is 1 percent of sessions and 25 users. You can raise or lower that. The point is a mail while the break is still new, not a chart you open next month.

Sentry alerts take action when an issue matches a rule you write. The docs say an alert can send a note, open a ticket, or call another service. Issue monitors and alerts split the work: a monitor decides when something is an issue; an alert decides what to do next, including a Slack message or an email. Write one rule: a new issue on the live app mails the named owner.

The store is a late clock. Android vitals (updated 9 October 2026) treats user-perceived crash rate as a core vital. The bad-behavior line is 1.09 percent of daily active users across devices, 8 percent on one phone model, and 4 percent on one watch model. User-perceived “app not responding” (ANR) is 0.47 percent overall. Play uses the last 28 days. Play’s crash page (updated 21 September 2026) says crossing the overall line can make the app harder to find on every device. Play Console help says a warning can also show on the store listing. If Play is your only watch, you hear in weeks. Customers hear first.

Failed sign-ups and logins

The happy path is you signing in. The break is a stranger who cannot create an account, or who pays and never gets a seat. You will not see that on a homepage check. You see it when a new user row fails to appear, when the reset mail still points at localhost, or when the error list fills on `/sign-up` and `/login`.

If you use Clerk, a `user.created` event is a signed note Clerk sends to your app when someone registers. Clerk’s sync guide says that event is how you insert the first user row in your own table. Compare Clerk’s user list to your table on a clock. If Clerk has a user and your table does not, the note failed or your handler failed. That person may have paid. They still have no seat.

Watch the error list on sign-up and login the same way you watch crashes. A flood of failed password checks can be an attack. A flood of “user already exists” after a half-finished sign-up is a product break. A magic link that still prints `localhost` is a product break. None of those show up as “the site is down.”

Put Google Analytics 4 on the live host under a company property. Google says data collection may take up to 30 minutes to begin. Use the Realtime report to prove a stranger session arrived. A tag that only fires on the founder laptop is not a watch. Keep Administrator on a company inbox.

Payment messages that never arrive

A webhook is a signed message your payment company sends to your app when money moves, a card fails, or a subscription changes. Your app must answer with a success code quickly. If it does not, the payment company keeps trying — and your customer may already think they paid.

Stripe’s webhook docs say live mode retries a failed delivery for up to three days, waiting longer between each try. Sandbox mode retries three times over a few hours. You can resend from the Dashboard for up to 15 days, or from the command line for up to 30 days. The Event deliveries tab lists Delivered, Pending, and Failed. Open it. A Failed row is a person who paid and may have no access.

Subscriptions make the wait worse. Stripe’s subscription webhook page says that if your endpoint does not answer, Stripe keeps retrying for up to 3 days. During that time Stripe will not try to charge the customer until it gets a success. Stripe also sends you an email that the webhook is failing. A quiet inbox here is not calm. It is a charge that never started, or a seat that never opened.

The mail only lands if someone turned it on. Stripe team settings list “A webhook delivery fails” as a notification you can receive. Each person must set their own Communication preferences. If the only Stripe login is a contractor, the fail mail goes to the contractor. Name a company user. Turn the mail on. Workbench event destinations show the next retry time. That tab is the watch. A founder guess is not.

Confirm the hook URL is the live origin, not a builder preview and not a laptop tunnel. A leftover `*.lovable.app` or a tunnel dies when the laptop sleeps. Stripe will retry for three days. Your customer will not wait three days. They will write a review.

Slow pages: up is not usable

A page can answer and still be too slow to use. Uptime checks do not catch that. Google’s Web Vitals name three live measures for most visits — the 75th percentile, which means three out of four loads. Largest Contentful Paint (LCP) is how long the main thing on the page takes to show. A good LCP is 2.5 seconds or less. Interaction to Next Paint (INP) is how long the page waits after a tap. A good INP is 200 milliseconds or less. Cumulative Layout Shift (CLS) is how much the page jumps while it loads. A good CLS is 0.1 or less.

Google Search uses the same three lines. The Search Console Core Web Vitals report groups URLs as Good, Need improvement, or Poor. Poor LCP is over 4 seconds. Poor INP is over 500 milliseconds. Poor CLS is over 0.25. A URL group is only as good as its worst measure. If you only watch “the site is up,” a 6-second first screen can stay green forever.

Watch the pages that make money: sign-in, the first signed-in screen, and checkout. A pretty home page with a dead checkout is not a launch. If Search Console has no data yet, the visit count is still small. Keep the uptime clock anyway. Add the vitals report the week the first strangers arrive.

Treat those bars as clocks, not a quote. The short bars are the week you want. The long bars are what you get if the store or the Stripe retry window is your only mail. A customer does not wait 28 days to tell a friend the app is dead.

One owner, one inbox

Six signals with no owner is noise. One owner with no backup is a single point of luck. Write the name. Write the inbox. Write the backup. Write the halt click.

Route every clock to the same company inbox. UptimeRobot and Better Stack can mail that inbox. Crashlytics can mail it. Sentry can Slack or mail it. Stripe can mail a webhook fail if that user turned the preference on. Do not invent a second pile. A founder Gmail that also pays Stripe is not a path. A Slack no one opens on Saturday is not a path.

The owner must be able to halt the host without the builder chat. Host halt. Store track halt. Feature flag. If the only “stop” is “ask the chat to unpublish,” you do not have an owner. You have a hope. That halt test belongs on the production-ready page and the soft-launch gates. This page only asks: when the mail lands at 11 p.m., who is awake, and can they press it?

The daily loop

Run the watch as a loop. Check. Hear. Name. Halt or fix. Do not add a new screen in the middle of a red signal unless the signal is blocked without it.

Day zero, before you tell more people: write the six signals, the live URL, the support inbox, the halt click, and the owner. Send yourself a test fail from the uptime clock. Confirm the mail arrived. Send a test event from Stripe’s Workbench if you take money. Confirm the handler answered. If either test is quiet, you are not watched.

Each day, write what you saw in one dated note. A quiet inbox is a fact only if you proved the mail path this week. A silent crash list is a fact only if a reporter is on. Silence is not a pass when the clock was never plugged in.

What to do this week

Keep the week small. You do not need a full operations team. You need six clocks and one name.

1. Put a robot on the live origin. Home and sign-in. Five minutes is enough. Mail the company inbox.
2. Turn on a crash reporter. Crashlytics or Sentry. Turn on new-fatal or new-issue mail. Do not wait for Play’s 28-day window.
3. Watch new seats. If Clerk (or your auth vendor) sends `user.created`, compare it to your table. Watch errors on sign-up and login.
4. Open Stripe Event deliveries. Turn on webhook-fail mail for a company user. Confirm the hook URL is the live host.
5. Open Search Console vitals once strangers arrive. Until then, time the first screen yourself on a second phone.
6. Name the owner and the backup. Write the halt click. Press it once on purpose.

If a door is still red — no second owner, no repo you control, no halt — stop adding clocks and finish the people list. A watch cannot invent an Account Holder on Monday.

Next steps

Write the six signals. Plug in the clocks. Prove one test fail. Name the owner. Keep the store and the Stripe retry window as backup clocks, not the only clocks. Customers should not be your first reporter.

CodeCross is a product studio. The week after launch is a live host, a crash list, a payment-message tab, and one inbox that already got a test mail. If a clock is still silent and you want a second pair of eyes, book a conversation.

FAQ

Is a founder refresh the same as an uptime check?

No. A refresh is one phone, one moment. An uptime check is a robot that hits the live URL on a clock and mails you when the answer is not a success. UptimeRobot free checks run every 5 minutes. Better Stack free checks run every 3 minutes. Watch home and sign-in, not only the pretty first screen.

If Play crash rate looks fine, can I skip a crash reporter?

No. Android vitals looks back 28 days and uses a 1.09 percent bad-behavior line. A store-only watch is late. Crashlytics can mail you for a new fatal, or when one issue hits the default 1 percent of sessions and 25 users in 30 minutes. Turn those mails on.

What is a payment webhook in plain words?

A signed message Stripe sends to your app when money moves, a card fails, or a subscription changes. Your app must answer with a success code. Stripe retries a live failure for up to three days. Subscription hooks can hold a charge until that success arrives, and Stripe emails you that the hook is failing. Open Event deliveries. Failed means a person who may have paid and still has no seat.

How fast should the main part of a page show?

Google’s Web Vitals want the main thing on the page (Largest Contentful Paint) to show in 2.5 seconds or less for three out of four visits. A tap should wait 200 milliseconds or less. The page should not jump more than a 0.1 shift score. Search Console marks Poor if the main thing takes more than 4 seconds. Up is not the same as usable.

Who should get the alert mail?

One named person on a company inbox, with a named backup. Stripe sends webhook-fail mail only to users who turn that preference on. Sentry can Slack or email the same owner. A founder Gmail that also pays the bills is not a path. A twelve-person Slack with no name is not a path.

Does a green homepage mean sign-in still works?

No. A home page can stay up while `/login` returns an error, while reset mail still points at localhost, or while a Clerk `user.created` note never writes your table. Check sign-in on the same clock. Compare new vendor users to your own rows. Watch errors on sign-up and login. A pretty first screen is not a seat.