Skip to main content
Uptime monitoring

Know before your customers do

A check on a schedule, from outside your server, with alerts that are worth reading. Two consecutive failures before we email you, one success to clear it, and nothing at all when the fault is ours to fix.

14 days free. No credit card. No commitment.

Checked from outside

Nothing installed on your site

Same price

On renewal, every year

99.99%

Uptime, last 12 mo

Daily

Backups kept up to 30 days

E

190+

Tasks Ellie handles

What it is

A request, from outside, on a schedule

There is not much to it, and that is the point. Most of what makes a monitor useful is decided by what it refuses to tell you about.

  • Nothing is installed on your site

    We request a page the way a visitor would and record what came back. No plugin, no agent, no script tag, and nothing to keep updated. A monitor that needs the site working in order to report that the site is broken is not a monitor.

  • It runs from our side, not yours

    Checks are made from our infrastructure, outside the server your site runs on. If the machine hosting you stops answering, the thing watching it is not on that machine.

  • You choose what gets watched

    Monitoring is opt-in per site, and you pick the path. A lightweight status page is a better probe target than a heavy home page, and if you have one, use it.

  • Password protection needs no exception

    A protected site answers 401, and a 401 is a working server doing exactly what you told it to. We do not bypass the protection and we never hold your credentials.

What you set up, in one screen

Pick a site, pick a path, pick how often. Optionally say whether a 403 or a 404 should count as an outage, and how many consecutive failures you want before we email. That is the whole configuration.

  • Opt-in per site
  • No plugin
  • Any path
  • Email or webhook
  • On every plan

What counts as down

If the server answered, the server is up

This is the decision that separates a monitor you trust from one you filter into a folder, so it is worth being explicit about.

Down by default

The name does not resolve

DNS returns nothing for the hostname. Visitors get no further than their own resolver, so nothing else about the site matters yet.

The connection is refused, or never answered

The server is unreachable or nothing is listening. This and the timeout are the two failures a visitor experiences as "the site is just hanging".

The certificate cannot be verified

Expired, mismatched, or otherwise untrusted. A browser will refuse to load the page, so we treat it exactly as a browser does.

The server errors

Any 5xx. The request reached your site and your site could not produce the page - a crashed process, an exhausted pool, a fatal error in code.

Up by default

401, 403 and 404

The server answered. It refused, or it had nothing at that path, but it was awake and it made a decision - which is the question uptime asks. You can opt in to treating 403 or 404 as down when a lost document root would be an emergency for you.

429, and it is not even offered

Our own rate limiting and bot protection produce 429s, so alerting on one would mean paging you about your defences working. This is the one code you cannot switch on as a failure, on purpose.

Uptime is not correctness

A site can answer every check and still be serving the wrong thing. Uptime asks whether the server is responding, and it is the wrong tool for asking whether the content is right - which is exactly why a 404 does not page you unless you say it should.

From check to inbox

Two failures to open, one success to close

The asymmetry is deliberate. Being slow to raise an alarm costs you a minute; being quick to raise a false one costs you every future alert, because you stop reading them.

  1. We request the page

    On the interval you chose - every 15 minutes at the entry level, down to every minute on the top plan.

  2. One failure is noted, not announced

    It goes into the record immediately. It does not go into your inbox, because a single failed check is almost always a brief network blip somewhere between us and you.

  3. The second failure opens an incident

    Two consecutive failures is the floor, and you cannot set it lower. You can raise it to as many as ten if your site is one that flaps under load.

  4. We check whether it is us

    Before anything is sent, the whole sweep is classified. If every site on one of our servers is failing at that moment, this is a platform incident and it is worded as one.

  5. You are told once, not once per site

    If several of your sites are affected by the same event, that is one email covering them rather than one per site.

  6. One good check ends it

    Recovery is deliberately asymmetric. Two failures to open, a single success to close and send the all-clear - there is no upside to being slow with good news.

Why you cannot set it to one

A single failed check is almost always a momentary network problem somewhere between us and your site rather than a real outage. A monitor that emails about those is one you learn to ignore, and an ignored monitor is worse than none - so 2 is a floor rather than a default. Raise it if your site flaps under load; you just cannot go under it.

How fast is fast enough

Your plan sets the shortest interval available to you, from every 15 minutes at the entry level down to every minute at the top. At the fastest setting, two failed checks still means you hear within about two minutes.

When we do not email

Three things we record and refuse to alert on

Every one of these would be an easy email to send, and sending it would make the other alerts worth less.

  • It was our server

    When every monitored site on one of our machines stops answering at the same moment, that is our problem and the incident says so. You still get told, but you are told what it actually was rather than being sent to look at your own code.

  • It was inside a maintenance window

    An outage that starts inside scheduled maintenance is recorded and labelled, with no alert sent. One that starts outside a window and runs into it still alerts normally - the window is not a mute button for problems that were already happening.

  • It was probably us being wrong

    If a very large share of everything we monitor appears to fail at once, the likeliest explanation is a fault in our own monitoring rather than every customer going down simultaneously. We record it, we alert nobody, and we raise it internally.

None of them are hidden

Each one is written into the incident history with the reason attached, so the question you will actually ask weeks later - why did I not hear about this one - is answerable from the page rather than from a support ticket.

Where it lands

Your inbox, your endpoint, or the record

Two channels and a history. They are independent, which matters more than it sounds.

  • Email

    One message when a site goes down, one when it comes back, both with what we actually saw. Turn them off in your notification settings if you would rather watch the panel.

  • Webhooks

    site.down and site.up delivered to any endpoint you have configured, signed the same way every other Hostney webhook is. Wire them into Slack, PagerDuty, or whatever already wakes you up.

  • The history

    Every outage, how long it lasted, what we saw, and whether an alert was sent - kept for 90 days. "Why did I not hear about this one" has an answer weeks later.

Turning email off does not silence your webhooks

A webhook is an integration you built on purpose, and quietly dropping its events because of an unrelated email preference would look like a fault on our side. The notification setting governs what we send you; it does not govern what we send your systems.

What it sits next to

Knowing is the first layer, not the only one

A monitor tells you something went wrong. These are the parts that make that rarer, and the part that gets you back.

  • Bot detection

    Most of the load that takes a small site down is not visitors. Scoring and challenging it before it reaches your PHP is what keeps the monitor quiet.

  • Container isolation

    Every site runs in its own container with its own limits, so one site exhausting itself is one incident rather than a shared afternoon.

  • Backups and recovery

    When the alert is about something worse than a restart, an immutable daily backup on separate infrastructure is what the next hour looks like.

Pricing

Simple, transparent pricing

Every plan includes managed WordPress, SSH access, daily backups, and enterprise-grade security. Start with a 14-day free trial.

Startup

Great for growing businesses

$7.99/mo

$94.99 billed annually

  • 1 website
  • 10 GB storage
  • ~10,000 visits/month
  • 5 MySQL databases
  • 250,000 inodes
  • 5 FTP users

What's included:

SSL & Domain

  • Free SSL certificate
  • Free starter domain

Apps & CMS

  • 1-click WordPress
  • Managed WordPress
  • WordPress staging
Most popular

Advanced

For professional websites

$14.99/mo

$179.99 billed annually

  • 5 websites
  • 20 GB storage
  • ~110,000 visits/month
  • 10 MySQL databases
  • 500,000 inodes
  • 10 FTP users

Everything in Startup, plus:

Backups

  • 14 days of backup history

Performance

  • Memcached

Monitoring

  • 5 minutes between checks

Pro

Maximum performance and features

$22.99/mo

$274.99 billed annually

  • 10 websites
  • 40 GB storage
  • ~200,000 visits/month
  • 20 MySQL databases
  • 750,000 inodes
  • 20 FTP users

Everything in Advanced, plus:

Deployment

  • 2 SSR applications

Backups

  • 30 days of backup history

Monitoring

  • 1 minute between checks

On every plan

Find out from us, not from a customer

Uptime monitoring is included on every plan, including the trial. Add a site, pick an interval, and get an email that is worth opening.

Questions

Frequently asked questions

Do I have to install anything?
No. We request a page from outside, the way a visitor would, and record the response. There is no plugin, no agent and no snippet to add - which also means there is nothing that can break along with the site it is supposed to be watching.
How quickly will I know?
Two consecutive failed checks open an incident, so the honest answer is roughly twice your interval. On the fastest plan that is about two minutes. You can raise the number of failures required if your site is prone to brief flapping, but you cannot go below 2 - that floor is what keeps the alerts worth reading.
My site returns 403 to visitors. Is that down?
Not by default, because the server answered - it was awake and it made a decision. If a 403 would be an emergency for you, switch it on when you add the site and we will treat it as an outage. The same option exists for 404.
What about a password-protected site?
It works with no special setup. A protected site answers 401, and that counts as up because it is a working server doing exactly what you configured. We do not bypass the protection and we never hold your credentials.
Will I get paged when your rate limiting kicks in?
No. A 429 is counted as up and cannot be switched to down at all. It is the one code we do not offer, because our own bot protection produces it and alerting on it would mean waking you up about your defences working correctly.
What happens if the outage is your fault?
The incident is labelled a platform incident rather than a problem with your site, and if several of your sites are affected you get one email covering them instead of one per site. The classification happens before anything is sent, by looking at whether every monitored site on that server failed in the same sweep.
Does an alert email mean my site is definitely broken?
It means the server stopped answering for at least two consecutive checks. That is a real event even when the site looks fine by the time you read the message - short outages are exactly the ones you would otherwise never find out about. The history page shows how long it lasted and what we saw.
Why does a site show a dash instead of an uptime percentage?
Because we have not checked it yet, and no data is not the same as 100%. A site that has never been probed is never counted as working - it is shown as awaiting its first check, and it sorts last rather than being treated as either perfect or broken.
What is the "not served by Hostney" label?
Every response we serve carries a header identifying the platform. If a monitored site answers without it, the request probably never reached us - the DNS points somewhere else, or the site was moved and the check was left behind. It is information rather than an alert: we never email about it and it never counts as downtime, but it tells you what the uptime figure on that row is actually measuring.
Is monitoring included, or is it an add-on?
Included, on every plan including the trial. What changes with the plan is how often we check - from every fifteen minutes at the entry level down to every minute at the top.