What Login Uptime Can You Promise an Enterprise Customer?

You can promise a customer an availability figure for login no higher than the figure you get by multiplying the availability of every component a sign-in passes through, and then you should leave some margin below it. In practice, a company whose identity setup depends on a hosted identity provider, its own application servers and a cloud host usually lands a little below the weakest commitment in that chain, so “99.9%” is only an honest answer once engineering has added up the pieces and checked what the identity provider’s own terms cover. Support response times work the same way: you cannot promise a faster response than the one your vendor gives you.

This post is for a CTO, VP of Engineering or founder at a B2B SaaS company whose first large customer has put an uptime and support commitment into the contract draft. It explains why the customer’s clause covers login, how to work out a figure you can support, what you inherit from your identity provider and what you carry yourself, and which terms are worth negotiating before you sign. It is written for the person who has to answer the question “can we just say 99.9%?” in an email.

Why does a customer’s uptime clause cover your login too?

To the customer’s users, a product they cannot sign in to is a product that is down. Login sits in front of everything else, so a login outage counts as full downtime even when every other part of your system is healthy. A contract that promises “the service” is available almost always covers sign-in, and a careful procurement team will say so explicitly.

What does the customer count as downtime?

Look at how the draft defines it. Some contracts define downtime as the service being unavailable, others as error rates above a threshold, and others as any failure to complete a defined transaction. Sign-in is nearly always one of those transactions. Read the definition before you decide on a number, because a definition based on error rates can be harder to meet than one based on total outages.

How does a login outage look to the customer’s own users?

Their employees open your product and cannot get in, and if the customer connects your login to their own company directory, the problem can look like it is in their system instead. They contact their own IT team first, so your outage becomes a support burden for your customer within minutes. The identity resilience post describes what keeps working during an outage (existing sessions, for a while) and what stops (new sign-ins and token refreshes).

What availability figure can your setup support today?

The honest figure comes from adding up the pieces and then leaving some margin below the result. It depends on your architecture and your vendors, and writing it down is the main thing engineering can contribute before anyone replies to the customer.

How do you add up the pieces between a user and your app?

List every component a sign-in depends on in sequence: your identity provider, your application servers and database, and the cloud platform they run on. The customer’s own directory is in the path their users experience, but leave it out of the chain you multiply, because it is outside your control and should be outside your commitment. When components depend on each other in a chain, their availabilities multiply, which is the method described in the availability section of the AWS Well-Architected Reliability Pillar for systems with hard dependencies.

For example, if your application is 99.95% available, your identity provider commits to 99.9%, and your hosting platform commits to 99.95%, the chain gives roughly 0.9995 × 0.999 × 0.9995 = 0.998, or about 99.8%. That is lower than any single figure in the chain, and it is the number a customer would be right to hold you to if you promised more. These commitments are targets and not measurements, so your real availability can be better or worse, and a figure you have measured over a year is stronger evidence than one copied from a vendor’s page.

What does a promised percentage mean in minutes of allowed downtime per month?

Turn each candidate figure into minutes, because that is how a customer will judge it after an incident. For a 30-day month (43,200 minutes):

A single bad deployment, certificate expiry or provider incident can use up a whole month of 99.9% in one go. If your team has had an incident longer than 43 minutes in the last year, that is a direct reason to quote a lower figure or to improve the system first.

Which commitments do you inherit from your identity provider, and which do you carry yourself?

You inherit the provider’s availability and support terms for the part they run, and you carry everything else: how your app handles a provider failure, how fast your team responds, and what you told the customer.

How do you read a vendor’s availability and support terms for what they do not cover?

Look at four things in the provider’s terms: what the availability figure applies to (the whole service, or only some features), what is excluded (planned maintenance, issues caused by your configuration, third-party outages), how downtime is measured, and what the remedy is. In many services the remedy is a service credit on the next invoice, not compensation for the customer’s loss. If you promise your customer a credit larger than the one you receive, you are carrying the difference.

Also check which plan the commitment belongs to. With Skycloak, for example, the Business plan carries a contractual 99.9% monthly uptime SLA with service credits on its included Medium cluster, Enterprise goes up to 99.99%, and Developer and Launch are best effort, as the SLA page sets out. The same question applies to any vendor: the figure on a marketing page may only apply to the top tier.

What support hours and response times do you inherit by plan, and what must you not promise beyond them?

Your response to the customer cannot be faster than the support you get from the vendor behind it, unless your own team can fix the problem without the vendor. Support is also tiered by plan, and for Skycloak it works like this:

If your customer asks for 24/7 support with a one-hour response, check that the plan behind your login covers it, and for any provider, whether the 24/7 coverage is a standard part of the plan or an add-on. The hosting page lists what each plan includes, and the pricing page shows the plans. Whatever your vendor offers, do not promise your customer a response you could not deliver yourself during an incident.

Which terms are worth negotiating before you sign?

The definitions matter more than the headline number, because a generous percentage with a strict definition can be harder to meet than a lower percentage with a fair one.

How is downtime measured, and what is excluded?

Ask for the measurement window (monthly is usual, and quarterly is easier on you), the measurement method (whose monitoring counts), and the exclusions. Planned maintenance with advance notice, failures of the customer’s own systems or network, and events outside your reasonable control (a major cloud region outage, for instance) are common exclusions. Make sure the customer’s own directory is explicitly out of scope if they use single sign-on, since you cannot fix it.

What about service credits, maintenance windows and notice periods?

Ask your counsel about making service credits the exclusive remedy for missing the target, and about capping them, so one bad month does not become an open-ended liability. Agree the maintenance windows and the notice period in advance, ideally at times when the customer’s users are least active. The buyer-side view of the same terms is in identity service procurement: contract negotiation and SLA requirements, which is useful for seeing what the other side will ask for. If you want the engineering side of the same numbers, how many nines Keycloak authentication needs covers the availability you build for, whereas this post covers what you can sign given your vendors’ terms. For the wider enterprise-readiness picture, see how long it takes to become enterprise-ready on login and why SSO alone does not get you through procurement.

What should you decide this week?

Answer these questions with engineering before you reply to the customer’s draft:

1. Which components does a sign-in depend on, and what does each one commit to in writing?
2. What was our measured login availability over the last twelve months, and what was our longest outage?
3. What figure does the chain support, and what margin do we want below it?
4. How does the draft define downtime, and does that definition match what we can measure?
5. Which support hours and response times does our vendor give us, and are we promising anything beyond them?
6. What remedy are we offering, and is it capped and exclusive?

The security page lists what we publish about our own controls.

Frequently asked questions

Can we just say 99.9% uptime?

Only after engineering has added up the availability of every component in the sign-in path and checked your measured history. At 99.9% you have about 43 minutes of downtime per month, so one long incident can break it. If the chain supports less, promise less, or improve the system before you sign.

What uptime do enterprise customers expect for SaaS login?

It varies by customer and contract, and there is no single standard. The login is normally included in whatever figure the contract sets for the service as a whole, so treat the customer’s number as a starting point for negotiation and work out what your own setup supports.

Does a vendor’s SLA mean we can promise the same to our customers?

No. Their SLA covers their service under their terms, with their exclusions and their credit as the remedy. Your promise covers your whole product, so it has to account for your own systems as well, and for the difference between the credit you get and the one you owe.

Does Skycloak offer 24/7 support?

On the Enterprise plan, yes. Other plans have business hours or extended weekday hours, as shown in the table above and on the SLA page.