Leave the office Wi-Fi
Open the site on a phone, on mobile data. A page that fails only on the office network is not an outage.
A site can fail on your Wi-Fi and be fine for everyone else. It can also look fine on your laptop and be dead for a customer in another city. Before you tell anyone the site is down, check it from outside your own network.
No account. The check does not use your browser cache, and it does not fix the site.
Cached page, office Wi-Fi. This does not mean a customer can buy.
Checked from outside your network. The server did not respond.
If only your machine fails, it is you. If the outside check fails too, it is the site.
Do not tell customers the site is down, and do not ask anyone to restart it, until a second place agrees with you.
Open the site on a phone, on mobile data. A page that fails only on the office network is not an outage.
Use the free uptime check. It asks the site from another region, so your cache and your DNS are not in the way.
The person who looks after the site can open the hosting panel and read the host status page. If that panel will not load, the host may be what is down.
A single red browser tab does not tell you which one you have. The check should name it, so you can see what happened and the person who looks after the site knows where to start.
DNS is wrong, or the domain expired. The server may be fine.
The site can be up and still be blocked, because the certificate expired or the name does not match.
A 500 is not “no answer”. Something on the site broke. A 200 with an error page is still a failure.
Your laptop and one region can disagree. A check from a single place will lie to you.
You see the site. A new visitor does not. That is why the check has to come from outside.
Login, the form, or checkout can be dead while the URL still returns a page.
An uptime check asks whether a URL responded. It does not click Pay, submit the form, or wait for the email. A customer can be stuck while every uptime check is green. You see that the sale failed. The person who works on the site sees which step broke.
The homepage returns 200 from every region you check.
Pay now throws before an order exists. The page is up. The sale is not.
The login page answers, and the certificate is valid.
The password reset never arrives, so the customer cannot get back in.
Every probe location can open the homepage.
Checkout fails from one city only. The other cities still complete the order.
A free check answers the moment. It does not watch the site after you close the tab. You should hear about the next failure before a customer does. Your developer, your agent, or the person who works on the website should get the alert they can act on.
Login, the form, checkout, and the page that takes the order. More than one region. Not every URL on the site.
A certificate and a domain fail on a date you can see coming. Warn before that date. Do not wait for the browser error.
You hear that it failed. So does your developer, your agent, or the person who works on the website. Email, Slack, or Teams. A status page answers the same question for everyone else. The alert does not change the site.
Choose how often you are told, and how, when a test fails. A single blip should not page anyone.
You can add the checks yourself. When you want the first ones chosen with you, we start with a look at the business on the site, the journeys to protect, and those tests in your account, sized to the plan. We also tune the alerts and the incidents: how often you are told, and how, when a test fails.
Start with the address a customer actually opens. Add login or checkout when you want a journey, not another URL ping.
You, and the developer, agent, or person who works on the website. One channel they already read. A status page is for everyone else asking if it is just them.
Point a check at a URL you know will fail. Confirm the right person got it, and that it did not fire on a single blip. Then point it back at the real site.
It answers the moment. It does not watch the site after you close the tab, and it does not tell you tomorrow.
No. It means that URL responded. A journey is what clicks through login, a form, or payment.
No. The alert goes to your developer, or to the person who works on the site. We can set the checks and the alerts up. We do not change the code.
The journeys worth protecting, the first tests in your account, and how the alert should fire. How many tests depends on the account. A single blip should not page anyone.
Tell us a little about your organisation and what you'd like to monitor.