What is uptime, and what is PulZone?

Uptime is the share of time a service answered correctly. This is what the number actually measures, why the "nines" are less solid than they look, and where the name PulZone comes from.

Uptime is the share of a period during which a service was available and answering correctly. If your site served requests for every minute of January except a twenty-minute stretch on the 14th, your January uptime was 99.955%.

That is the whole definition. Everything interesting is in the words "available", "answering correctly", and — the one almost nobody examines — "you measured it".

The arithmetic, and the table everyone quotes

Uptime is usually written as a percentage of wall-clock time, and the industry has settled on talking about it in "nines". The nines are seductive because each one sounds like a small step and is in fact a tenfold reduction in the downtime you are allowed.

Two things fall out of that table immediately.

The first is that 99% is a bad number wearing a good number's clothes. It reads as "almost perfect" and it means your service can be unreachable for the better part of four days a year. If you have ever seen a hosting company advertise "99% uptime guaranteed" and felt reassured, look at the table again.

The second is that five nines is not a target most organisations can honestly set. Twenty-six seconds of downtime a month is less than a single careless deploy, less than one certificate renewal that goes sideways, less than one kernel reboot. Claiming five nines commits you to an architecture — redundant everything, zero-downtime deploys, automated failover that has actually been tested — that costs vastly more than most services are worth. Three nines is a serious, achievable, defensible target for a small team. Four is real work.

What counts as "down" is a decision, not a fact

Here is where uptime stops being arithmetic.

Suppose your server responds to every request in 200 milliseconds, returning a perfectly valid HTTP 200, and the page it returns says "We're experiencing technical difficulties." Is the site up?

Your web server thinks so. Your load balancer thinks so. A naive uptime monitor thinks so. Your customers do not, and they are the only opinion that has ever mattered.

Now suppose your API returns 200 OK with a body of {"data": null, "error": "upstream timeout"}. Up or down? Suppose the page loads but the checkout button 500s. Suppose everything works but requests take eleven seconds. Suppose the site is perfect but your TLS certificate expired forty minutes ago, so every visitor gets a full-page browser warning telling them your site is dangerous.

Every one of those is an outage to the person trying to use your service, and none of them is an outage to a monitor that only asks "did something reply?"

So the honest definition of uptime is narrower than the popular one:

Uptime is the share of time your service did the specific thing you needed it to do, verified by someone who was not your service.

Both halves of that matter. "The specific thing" is why a good check asserts on content, status and latency rather than mere reachability. "Someone who was not your service" is why a monitor running on the same box it monitors is not a monitor — when the box dies, so does its opinion of itself.

The measurement problem nobody mentions

There is a third quiet assumption in every uptime figure: that you were looking.

Uptime monitoring is sampling. You check every 30 seconds, or every minute, or every five minutes, and you infer the state of the world in between from the samples you took. That inference is usually fine and occasionally very wrong.

If you check every five minutes and your service is down for three minutes, there is a good chance you will not record a single failed check. Your dashboard will show 100% uptime for a period in which real users got real errors. The outage happened; you just did not sample it.

This has a consequence that is worth stating plainly, because it cuts against the way uptime is marketed:

Your check interval sets a floor on the downtime you are able to detect, and therefore a ceiling on the uptime figure you can honestly claim.

With five-minute checks, you cannot meaningfully assert four nines. Four nines allows 4.38 minutes of downtime per month — less than one sampling interval. The number is not measurable at that resolution. You can print it on a page, but you have not observed it.

This is the real reason check intervals appear on pricing pages, ours included. It is not an artificial lever to make you upgrade. Faster checks buy you finer resolution, and resolution is what turns an uptime percentage from a marketing claim into a measurement. If you are running a hobby project, five-minute sampling is completely adequate and you should not pay for more. If you are publishing an SLA with penalties attached, sample faster than the SLA you are promising.

What uptime does not tell you

Even a correctly measured uptime figure is a narrow instrument, and it is worth knowing what it leaves out before you use it as a scorecard.

It says nothing about degradation. A service that answers every request in eleven seconds is up by any binary definition and unusable by any human one. The checkout completes, the monitor is green, and the customer left four seconds in. If uptime is the only thing you watch, this failure mode is invisible until it shows up in revenue, which is a slow and expensive way to learn about it.

It says nothing about who was affected. A CDN edge failing in São Paulo and a total outage produce very different customer experiences and can produce the same headline number, especially if your probes happen not to sit in the affected region. Uptime measured from three places is an average of three opinions, not a fact about your users.

And it says nothing about correctness beyond the check you wrote. A monitor confirms the assertion you gave it. If you asserted that the homepage contains the word "Login", you have verified precisely that, and a checkout that started rejecting every card an hour ago will not disturb the green dot.

None of this makes uptime a bad metric. It makes it a floor: the thing that has to be true before any other quality question is worth asking. Treat 100% uptime as the absence of a specific disaster rather than as evidence that things are going well, and it will serve you honestly.

Where the name comes from

PulZone is spelled with a capital P and a capital Z, one word, no space and no hyphen: PulZone. It is pronounced the way it reads — pulse zone.

The name is those two words compressed, and they were chosen because they are the two halves of the thing.

The pulse

A monitor is a heartbeat. It sends the same small request, at the same fixed interval, forever, and it cares about exactly one thing: whether the answer came back the way it should. That is a pulse in the medical sense — not a diagnosis, not a full picture of health, but a regular, dumb, reliable signal that tells you immediately when something has stopped.

The pulse metaphor also carries the failure mode. A pulse is only useful because it is continuous. A doctor who checked your pulse once a quarter would not be monitoring you. Neither is a status page that someone updates by hand after being told there is a problem.

And, as with a real pulse, its absence is informative in a way its presence is not. A returning heartbeat tells you the patient was alive at that instant. A missing one tells you to go and look right now.

The zone

The second half is the part most people discover the hard way.

A pulse taken from one place is a rumour. If a single probe in Frankfurt cannot reach your server, you know one of these things is true: your server is down, the network between Frankfurt and your server is broken, your firewall started rate-limiting that probe, a BGP route flapped, or the probe itself has a problem. Exactly one of those five is worth waking someone for.

A zone is where you check from. Checking from several zones and requiring agreement before declaring an outage is the difference between a monitoring system and a random pager. It is also the difference between "the site is down" and the far more useful "the site is down from Europe", which is a sentence that has already told your engineer where to look.

So: the pulse is the check, the zone is the vantage point, and neither is worth much without the other. That is the name, and it is also the design.

What PulZone actually is

PulZone is a hosted uptime monitoring service. You point it at the things you care about, it checks them from several places at once, and it tells you — and your customers, on a status page — when one of them stops answering properly.

The design decision that shapes everything else is what goes on the free plan. Most monitoring is sold by feature: uptime checks on the entry tier, SSL expiry one tier up, an API assertion on the plan with a "contact us" button, a status page as a separate subscription. That works commercially and it is miserable to live with, because the check you need is always the one you do not have, and you find out during the outage.

So PulZone meters scale instead. Every account gets every check type, every alert channel, a status page and the full API. What the paid plans buy is more monitors, more seats, faster check intervals and more probe regions — the things that genuinely cost us money to give you.

What it watches

• HTTP and keyword checks — including the case above, where the page returns 200 and contains the words you least want to see. See keyword monitoring.
• API checks — assert on status code, response time, headers and JSON body content, not just reachability.
• SSL certificate expiry — warned about weeks ahead, rather than discovered from a customer's screenshot of a browser warning.
• Ping and TCP port checks — for the machines and services sitting behind the website.
• Cron heartbeats — a URL your scheduled job calls when it finishes, so that a nightly backup which silently stopped running three weeks ago becomes an alert instead of a discovery during a restore.
• Domain expiry — the outage that lasts days because nobody renewed a domain name.

Every one of those is available on every plan, including the free one. We do not hold a monitor type back to make a higher tier look better.

Alerts, and not being woken for nothing

When a check fails, PulZone confirms the failure from a second location before it alerts anybody. This is the "zone" half of the name doing its job: a flaky network path between one probe and your server is not an outage, and a monitoring system that pages you for it will be muted within a fortnight. A monitor you have muted is worse than no monitor, because you still believe you have one.

Alerts go to email, webhooks and chat, and each account manages its own contacts. Status pages are included on every plan, on your own domain if you want one — see status pages.

The free tier

Fifty monitors, checked every five minutes, free forever. No card, no trial clock, no expiry that turns into a phone call. If that covers you, it covers you, and we would rather have you on it than not have you at all.

Where to go from here

If you want the case for monitoring at all, read why checking uptime is not optional.

If you are convinced and want to do it well rather than merely do it, read how to check website and service status properly — which is mostly about avoiding the "200 OK with a broken page" trap described above.

And if you want to see how we compare to what you are probably using now, we keep an honest list, including the parts where we lose: vs UptimeRobot, vs Pingdom, vs Better Stack.