How to check if a website is down: for everyone, or just for you

The short version

Two questions hide inside "is my website down". One is about right now: is it down for everyone, or only where you sit, on your network or in a stale browser cache. The other is about next time: whether you hear about an outage from a monitor or from a customer. The first question has a one-minute answer that needs no account: type the domain on upcontrol.io and a public status page for that host exists from that moment, with the measurement on it. The second takes three checks and free alerts, and the incident that opens carries its cause in the title.

What checking covers on the free plan, from the pricing sheet as of 2026-10:

Down for everyone, or only for you

1. Open upcontrol.io and type the domain. The page exists from that moment and it is public: anyone you send the link to reads the same measurement.
2. Read what the probes saw. An outage is declared after three failed checks in a row, not after one, so a blip stays a blip on the record instead of a red row.
3. If the host is yours, claim the page from its link into your account and wire checks and alerts onto it.
4. Still loads for you? Then the checks passing and your browser failing points at the path in between, and the usual next test is a different connection, a phone on mobile data.

The same rule runs the other way: a check that answers 200 with a slow page is up, and the response phases stored on every check (dns, tcp, tls, wait) say which part of the answer was slow.

Hearing it from a monitor first

The page answers "is it down". Monitoring answers "when did it start and what broke", and on the free plan that means:

• Three website checks, every 5 minutes, counted workspace-wide. The marketing site, the API, the route the money moves through: each gets its own check and its own component on the page.
• An incident opens after three failures in a row and is titled with the cause, "Checkout returning 502" or "DNS error", not only "down".
• SSL and domain expiry watched on every check, on every plan.
• Scheduled jobs get heartbeats: every 5 or 30 minutes, hourly, every 6 hours or daily. A missed ping opens an incident at most an hour past its due time, and heartbeats never touch the check count.
• Alerts to Telegram, Slack, Discord and email, unlimited on Slack, Discord and email, three Telegram recipients on free.

Why it went down

The harder half of the question is the why. Logs and product events answer it, and a coding agent wires them: run npx upcontrol in the repo and the agent you already use (Claude Code, Cursor, Codex, Gemini CLI, Copilot, Windsurf, Amp, Aider, Cline, opencode) adds the logging. Ask in plain words, "track my users from first visit to purchase", and the funnel lands on the dashboard with no tracking code written by hand.

The payoff at 3am: an incident page that 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, and raw log lines are kept 31 days. That is the product in one line, monitoring that arrives with the why, not just down.

What free does not cover

Honest limits, from the same sheet:

• Every 5 minutes, not every minute. Paid plans check every minute and carry 10, 30 or 100 checks.
• Three checks per workspace, counted across every project in it, not fifty. Heartbeats are extra and free.
• The fleet checks from its regions; there is no many-city synthetic probe network advertised. What is stored instead is the response phases per check, so "slow" has a name.
• No on-call scheduling, rotations or phone/SMS escalation. Alerts go to Telegram, Slack, Discord and email, and that is the whole list.
• Younger product: fewer integrations than the decade-old incumbents.

The one-minute answer, no account and no card: [type the domain on upcontrol.io](https://upcontrol.io/?utm_source=blog&utm_medium=vs&utm_campaign=engine).