What to check on a launch day
5 min read ยท published 2026-10-10
The short version
Launch day is when a five-minute DNS mistake or a cert that expires on the wrong Tuesday costs the whole week of attention you just paid for. The checks that matter are few, and most of them take an afternoon. This is the list, and where each item lands in UpControl, from the product sheet as of 2026-10.
| What to check | What watches it |
|---|---|
| The URL people will actually hit | a website check, every 5 minutes on free, every minute on paid |
| The checkout or signup path | another check, its own incident title ("Checkout returning 502") |
| SSL certificate and domain expiry | watched on every check, every plan, no extra setup |
| The job behind the launch (emails, imports) | a heartbeat, free, cadences from 5 minutes to daily |
| The status page | public before launch, at upcontrol.io/status/yourdomain |
| New errors in the logs | alerts on new errors, every plan including free |
| Whether signups actually happen | product events, wired by the coding agent |
| What visitors do on the page | one script tag: page views, referrer, UTM, heat |
The checks themselves
A website check opens an incident only after three failures in a row, which keeps a single blip from paging anyone during the busiest hour. The incident is titled with the cause, "Checkout returning 502" or "DNS error", so the first glance says what broke and where.
Three checks cover a small launch on the free plan; the count is the workspace's, across every project in it. Paid plans start at $11/month ($9 annual) for 10 checks at every minute.
One rule matters more than the count.
The two silent ones: SSL and the domain
SSL and domain expiry are watched on every check, on every plan, no extra setup. A cert that expires on launch day or a domain that lapses the week after are both caught while they are still a Tuesday problem instead of a public one.
The job behind the launch
Something on launch day is a scheduled job: the launch email, the import, the digest an hour after the post. A job that stops running pages nobody; cron starts the command and takes no interest in how it ends.
Give it a heartbeat: the job pings a URL when it finishes, the monitor expects the ping on its schedule, and silence opens the incident, at most an hour past the due time. Heartbeats are free on every plan, never count toward the check limit, and run from 5 minutes to daily.
The status page, live before the launch
Put the status page up before anyone asks for it. Type the domain on upcontrol.io and a public page for that host exists from that moment, no account, no card; the site's owner can claim it into their account later. It carries components, incidents and uptime history, so "API degraded" can show while the site itself still answers. A custom domain for the page is a paid feature; the upcontrol.io/status/yourdomain address is not.
During the launch, the page answers customers before you can. A tweet reaches you in ten minutes; a link in the footer reaches them in one.
Why it broke, on the same page
Uptime tells you the launch broke. The why comes from correlation: the incident page carries the deploy that landed before the failure and the log lines around it, not only "down since 12:04". Alerts fire on new errors in your logs on every plan including free, and paid plans add a 15-minute follow-up that says whether the incident recovered or is still down. Raw log lines are kept 31 days.
The wiring is one command: npx upcontrol in the repo hands the setup to the coding agent you already use (Claude Code, Cursor, Codex, Gemini CLI, Copilot, Windsurf, Amp, Aider, Cline, opencode), and you ask in plain words, "log errors from the checkout service". No tracking code written by hand.
Watching the launch itself
Uptime says the site stayed up. These two layers say whether the launch worked.
Product events: ask the same agent to "track my users from first visit to purchase" and the funnel lands on the dashboard, built from events sent through one npx package. Funnels, retention, breakdowns and A/B tests read the same events; a Go, Rust or browser sender needs no SDK at all.
Web analytics: one script tag in the head of every page. It records page views with path, referrer, UTM tags, country and device, plus clicks, rage clicks and scroll for heatmaps, drawn over your own live page, per device. No cookies and nothing stored on the visitor's device; a visitor is a daily-rotating hash, so one person counts once a day. On the free plan that is 3,000 visits a month and heatmaps for the 5 busiest pages; web history reaches back at most 31 days, on every plan.
The afternoon before launch
- Run
npx upcontrolin the repo and ask the agent in plain words to watch the launch surface and log its errors. - Type the launch domain on upcontrol.io so the status page exists before anyone asks; claim it and link it from the footer.
- Add the checks: site, API, checkout. SSL and domain expiry come with every check, no extra setup.
- Give the launch job a heartbeat matched to its schedule; silence opens the incident.
- Pick where alerts go: Telegram, Slack, Discord or email, unlimited on every plan.
The honest limits
- No on-call scheduling, rotations or phone/SMS escalation. Alerts go to Telegram, Slack, Discord and email, unlimited on every plan. If launch day needs a phone tree, pair it with something that makes phone calls.
- Free is 3 website checks at every 5 minutes, counted workspace-wide. Heartbeats are extra and free.
- No synthetic multi-region probes advertised from many cities; the fleet checks from its regions, and response phases (dns, tcp, tls, wait) are stored per check.
- Web analytics is young: no session recordings or replays, heatmaps only for the plan's busiest pages, at most 31 days back. Tools built for analytics alone go deeper.
- UpControl is a younger product with fewer integrations than the decade-old incumbents.
The whole stack, checks to funnel, is [one npx command](https://upcontrol.io/?utm_source=blog&utm_medium=vs&utm_campaign=engine).