How much downtime does 99.9% uptime allow per month?

In a 30-day month, 99.9% allows 43.2 minutes of downtime. Over a 365-day year, that is 8.76 hours.

What is the difference between uptime and an SLA?

Uptime is the measurement: the percentage of time the service responded. An SLA is the contract where the provider commits to a minimum percentage and defines the compensation if it misses it, usually bill credits.

Does a 99.9% SLA guarantee my app will not go down?

No. The SLA defines financial compensation if the provider fails, and it almost always covers only the provider's own infrastructure. Bugs in your code, out-of-memory kills and configuration mistakes are excluded.

Is 99.99% much better than 99.9%?

Each extra nine divides the allowed downtime by ten: from 43 minutes to about 4 minutes per month. It is only worth the cost if a 43-minute outage causes real damage to your business.

How do I know my app's real uptime?

Measure it from the outside with an external monitor that checks the app every minute. The number a provider publishes measures its infrastructure, not your code.

What does 99.9% uptime actually mean?

"99.9% uptime" shows up on almost every hosting page. The number sounds like a promise that the service almost never goes down, but it says little without two more facts: the period it is measured over and what happens when it is missed.

Before you depend on it, learn to do the math and to tell an internal target from a contract with compensation.

What is uptime?#

Uptime is the percentage of time a service was available during a period. The formula is simple:

uptime = (total time - downtime) / total time x 100

If an app was down for 20 minutes in a 30-day month (43,200 minutes), uptime was 99.954%. The measure only makes sense with a clear definition of "available". It might mean returning HTTP 200 within 5 seconds, accepting a TCP connection or, for a bot, staying connected to the Gateway. Each definition gives a different number for the same incident.

How much downtime does each percentage allow?#

To get the allowed downtime, multiply the period by the unavailable fraction (100% minus uptime):

Uptime	Per day	Per month (30 days)	Per year (365 days)
99%	14.4 min	7.2 h	3.65 days
99.9%	86.4 s	43.2 min	8.76 h
99.95%	43.2 s	21.6 min	4.38 h
99.99%	8.6 s	4.32 min	52.56 min
99.999%	0.86 s	25.9 s	5.26 min

You can redo the math for any value in Node.js:

const minutesInMonth = 30 * 24 * 60; // 43200

for (const uptime of [99, 99.9, 99.99, 99.999]) {
  const downtime = minutesInMonth * (1 - uptime / 100);
  console.log(`${uptime}% -> ${downtime.toFixed(2)} min/month`);
}

Each extra "nine" divides the allowed downtime by ten. Google's SRE book describes each additional nine as an order-of-magnitude improvement toward 100%, and it states that 100% is probably never the right reliability target.

What is the difference between SLI, SLO and SLA?#

The three terms get mixed up, but they describe different layers:

SLI (service level indicator): what you measure. Example: the fraction of requests answered successfully.
SLO (service level objective): the internal target for the SLI. Example: 99.9% of requests succeed over 30 days. The team operating the service sets it.
SLA (service level agreement): the contract with the customer. It includes an SLO and the consequences of missing it.

In practice, an SLO is a target, and an SLA is a target with financial compensation. Neither prevents an outage. The SRE book also introduces the error budget: the downtime the SLO tolerates. With a 99.9% SLO measured over 30 days, the budget is 43.2 minutes, and the team can "spend" it on deploys and maintenance instead of chasing zero.

What does an SLA actually guarantee?#

Almost always, an SLA guarantees compensation, not availability. Take the shape of the Amazon EC2 Region-Level SLA: an availability commitment per monthly billing cycle, with service credits that grow as uptime drops. The table below shows a hypothetical SLA in that shape, with round percentages chosen to keep it easy to read. They are not any vendor's figures; the real values are on the official SLA page.

Monthly uptime (hypothetical)	Credit
Below 99.9% but at least 99%	10%
Below 99% but at least 95%	25%
Below 95%	50%

Notice four details that repeat in nearly every SLA:

The credit is a share of the affected service's bill (with AWS, that month's EC2 bill in the affected Region), not of the loss the outage caused you.
You have to ask for it. With AWS, you open a support case with dates, affected resources and logs, by the end of the second billing cycle after the incident.
A credit is not a refund. It offsets future charges.
There are architecture conditions. The EC2 Region-Level SLA only applies to instances running across two or more Availability Zones.

Beyond that, SLAs usually exclude scheduled maintenance, failures caused by the customer and force majeure. Always read the exclusions section before comparing two providers.

Why can your app's uptime be lower than your host's?#

The provider's percentage measures its own infrastructure. Your app depends on more things in series, and total availability is the product of the parts. A host at 99.9%, a database at 99.9% and a third-party API at 99.9% give 0.999 x 0.999 x 0.999, or about 99.7%: close to 2.2 hours per month.

Several common causes of downtime also fall outside any infrastructure SLA:

unhandled exceptions that kill the process;
running out of memory (the process is killed for exceeding its RAM);
deploys that restart the app and take it down for a few seconds;
revoked tokens, expired certificates and expired domains.

That is why you should measure it yourself. An external monitor that checks the app every minute gives the number that matters: what your users saw. For bots with no HTTP port, see how to monitor your bot's uptime.

How much uptime do you really need?#

It depends on the cost of being down, not on the highest possible number:

99% (about 7 h per month): fine for a personal project, an internal tool or a small community bot.
99.9% (about 43 min per month): a reasonable default for small and mid-size commercial sites and APIs.
99.99% or more: needs real redundancy, with several instances, automatic failover and usually more than one region. Cost and complexity climb fast. See what a load balancer is for the basis of that architecture.

The SRE book makes a fair point: a typical user cannot tell 99.99% from 99.999% when their own phone and network are less reliable than that. Most projects are well served by 99.9%.

If you are still choosing where to host, also compare the operating model in VPS vs cloud platform: on a VPS, patching, restarting and monitoring are your job.

How to do this on Square Cloud#

The same reading applies on Square Cloud: availability is a target, not a guarantee. Applications run in isolated, always-on containers, with no cold start and no sleep mode, and automatic restart (on by default for dashboard deploys) brings the app back when the process exits with an error. The observed average uptime is 99.99%, a historical figure, not a promise that the service will never stop.

Much of your uptime is still in your hands: handling exceptions, sizing each application's RAM and watching real-time logs and metrics in the dashboard. For a high-availability site or API, load balancing (from the Standard plan) spreads a custom domain across several applications, round-robin with passive failover. There is no autoscaling: you choose how many applications and how much RAM to use.

On the Enterprise plan, an SLA can be discussed with the team. The availability and monitoring capabilities are on the features page.