Uptime Isn't Reliability

Ask a software vendor about reliability and you will usually be handed an uptime number. Ninety-nine point nine percent. Ninety-nine point ninety-nine. It appears on the status page, in the contract, on the slide, presented as proof that the system can be depended on. It is a reassuring number, and for a property company evaluating the platform that will run its operations, it feels like the answer to the right question.

It is not, quite. Uptime measures one narrow thing: whether the system was responding. It does not measure whether the system was doing what you needed, correctly, quickly enough to be useful, at the moment you needed it. A platform can hit its uptime target and still fail you routinely, because the ways software actually lets a property operation down mostly do not register as downtime. The status page stays green while the thing you were relying on quietly does not work, and uptime, by design, never notices.

Availability and reliability are different things

This distinction is not wordplay. It is a formal one, drawn straight from the discipline that exists to keep large systems dependable.

In Site Reliability Engineering, the field Google established to run services at scale, availability and reliability are treated as related but separate. Google's SRE practice defines availability as the fraction of the time a service is usable, typically the proportion of well-formed requests that succeed, which is essentially what uptime captures: is it responding. Reliability is the larger question of whether the system consistently does what users actually need, correctly and acceptably, over time and under real conditions. A system can be highly available and still unreliable, because responding is not the same as working.

The gap between the two is where real failures live, and the SRE discipline is explicit about it: without clear definitions of what the service is actually supposed to deliver, users form their own beliefs about how reliable it is, and those beliefs collide with reality at the worst moments. Uptime is the number a vendor can put on a status page. Reliability is whether the system does its job when your team reaches for it, and only one of those two is what you are actually buying.

The ways a system fails while staying "up"

The reason uptime is a poor proxy for reliability is that most of the failures that hurt a property operation do not look like downtime. The system is up the entire time.

• It is up but slow: A platform that responds to every request but takes forty-five seconds to load the screen your team uses fifty times a day is, by the uptime metric, perfectly available. It is also, in any practical sense, failing, because a tool too slow to use is a tool that does not work, and your team feels that failure continuously while the dashboard shows green. Latency is a reliability problem that uptime cannot see.

• It is up but wrong: This is the most dangerous category, because it is invisible. A system that returns a number promptly, and returns the wrong number, is fully available and completely unreliable. A report that quietly pulls stale data, a balance that does not reflect the latest transactions, a calculation that applies the wrong rule, each of these responds instantly and successfully, and each one is a failure that uptime not only misses but actively disguises, because the fast, successful response looks like health. A system that is up but wrong is worse than one that is down, because down at least tells you not to trust it. This is the same reason a system's most abused claims deserve scrutiny rather than trust, examined for one such term in real-time is the most abused word in property software.

• It is up but not for the thing you need: A platform can be available overall while the specific function you depend on at month-end is the one that breaks, or degrades under exactly the load that month-end creates. Aggregate uptime averages across everything, so a critical function failing at a critical moment can be entirely real while the headline number stays reassuring. The average was fine. The moment that mattered was not.

• It is up but unusable after a change: A system that is technically running but has become confusing, mis-configured, or broken in workflow after an update is available and unreliable at once. Your team cannot complete the task, but no request failed, so nothing counts as downtime. The work does not get done, and the metric records success.

In every one of these, uptime reports health while the operation experiences failure. That is not a measurement error. It is what uptime measures, and it was never designed to measure the rest.

What this looks like in a property operation

The abstraction becomes concrete fast in property management, because the operation depends on the system being correct and usable, not merely responsive.

At month-end, the system is up, and the consolidated numbers it produces are subtly wrong because a sync did not complete, and the error is not discovered until an owner questions a statement. During a busy leasing period, the platform is available but so slow under load that the team falls behind, and every application takes three times as long to process. A tenant charge is calculated and posted promptly and incorrectly, at scale, because the system faithfully applied a rule that was wrong. In each case the vendor's uptime report for the period would show near-perfect availability, and in each case the operation was let down by the software in a way that uptime, by its nature, did not record. The number the vendor points to and the experience your team lived through describe different realities.

The honest part

Several qualifications keep this from becoming an argument that uptime does not matter, which would be wrong.

Uptime genuinely matters, and a system that is frequently down is unreliable in the most basic way. Availability is a necessary component of reliability, not a fake one, a platform your team cannot reach is failing them completely, and vendors who invest in high availability are doing real and valuable work. The argument is not that uptime is worthless. It is that uptime is necessary but not sufficient, a floor rather than the whole building, and treating it as the complete measure of dependability is the mistake.

It is also true that reliability is harder to measure than uptime, which is precisely why uptime gets used as the proxy. Correctness, speed under load, and usability are genuinely more difficult to put a single number on than "is it responding," and there is no dishonesty in a vendor reporting the metric that can actually be measured cleanly. The problem is the buyer accepting that clean number as an answer to a messier question, rather than the vendor offering it. Reliability being hard to quantify does not make uptime an adequate stand-in for it.

And good vendors care about reliability well beyond uptime, and can talk about it specifically, latency targets, data-correctness guarantees, performance under peak load, behavior during and after updates. The presence of those commitments, not just an uptime SLA, is a sign of a vendor who understands the difference. A vendor who can only offer uptime is telling you which of the two they measure. This is the same decoding discipline that separates a genuine capability from a marketing label, applied to another common claim in what "AI-powered" actually means.

Ask about reliability, not just uptime

The practical move is to stop treating the uptime number as the reliability answer and start asking about the dimensions uptime hides. When a vendor offers an availability figure, treat it as the beginning of the reliability conversation, not the end of it.

Ask what "up" actually means in their measurement, whether a slow-but-responding system counts as available, and what their latency commitments are for the screens your team uses most. Ask how they ensure the data the system returns is correct and current, not merely returned, since a fast wrong answer is their uptime success and your operational failure. Ask how the system behaves under the specific load your month-end or leasing peak creates, because aggregate uptime will not tell you. And ask what happens to reliability after an update, since a change that leaves the system running but unusable is invisible to the uptime metric and very visible to your team.

There is a single question that reframes the whole evaluation. When this system fails me, will it fail in a way your uptime number would even record? If most of the ways the platform could let your operation down, slow, wrong, degraded at the critical moment, unusable after a change, would not register as downtime, then the uptime figure is answering a question you did not ask, and reliability is the thing you actually need to evaluate. Uptime tells you the system will probably be responding. Whether it will be working, correctly and usably, when your operation depends on it, is the real question, and it is a different one.

FAQs

Q1. Isn't a high uptime percentage proof that software is reliable?
No, it is proof the system was responding, which is necessary but not sufficient for reliability. Uptime measures whether the system was available, not whether it was doing what you needed, correctly and quickly enough to be useful. A platform can hit a high uptime target while routinely failing your operation in ways uptime does not capture, because most real failures, slow, wrong, or degraded responses, still count as the system being up.

Q2. What is the difference between availability and reliability?
Availability, which uptime measures, is the fraction of time a system is usable, essentially whether it responds successfully. Reliability is the larger question of whether it consistently does what users actually need, correctly and acceptably, over time and under real conditions. The distinction comes from Site Reliability Engineering, the discipline Google established to run systems at scale, and it treats the two as related but separate, since a system can be available while being unreliable.

Q3. How can a system be "up" but still failing me?
Several ways, none of which register as downtime. It can be up but too slow to use, responding to every request while taking far too long. It can be up but wrong, returning fast, successful, incorrect answers. It can be up overall while the specific function you need at month-end degrades under load. Or it can be up but unusable after an update. In each case a response succeeded, so uptime records success while your operation experiences failure.

Q4. Why is "up but wrong" the most dangerous failure?
Because it is invisible and looks like health. A system that returns the wrong number promptly is fully available and completely unreliable, and the fast, successful response disguises the failure rather than revealing it. A report pulling stale data or a charge calculated with the wrong rule responds perfectly by the uptime metric while producing a real operational error. A system that is down at least warns you not to trust it; one that is up but wrong does not.

Q5. What does this look like in property management?
Concretely: month-end numbers that are subtly wrong because a sync did not complete, discovered only when an owner questions a statement. A platform so slow under leasing-peak load that the team falls behind, though it never goes down. A tenant charge posted promptly and incorrectly at scale because the system applied a wrong rule faithfully. In each case the vendor's uptime report shows near-perfect availability, while the operation was genuinely let down in ways uptime does not record.

Q6. Does uptime not matter then?
It matters a great deal; a frequently-down system is unreliable in the most basic way, and availability is a genuine and necessary component of reliability. The argument is not that uptime is worthless but that it is a floor rather than the whole building, necessary but not sufficient. Vendors who invest in high availability are doing real work. The mistake is treating that one number as the complete measure of whether a system can be depended on.

Q7. Why do vendors emphasize uptime if it's incomplete?
Partly because it is genuinely easier to measure. Correctness, speed under load, and usability are harder to reduce to a single clean number than "is it responding," so uptime becomes the convenient proxy. There is no dishonesty in reporting the metric that measures cleanly. The issue is on the buyer's side, accepting that clean number as the answer to the messier question of reliability, rather than pressing on the dimensions uptime cannot capture.

Q8. What should I ask a vendor instead of just uptime?
Ask what "up" means in their measurement and whether a slow-but-responding system counts as available. Ask their latency commitments for your most-used screens, how they ensure returned data is correct and current, how the system performs under your specific peak loads, and what happens to reliability after updates. A vendor who can speak to those specifics understands reliability; one who can only offer an uptime SLA is telling you that uptime is the only part they measure.