Is availability the same as reliability?

They are related, but reliability can encompass consistent correct operation over time, while availability focuses on usable access when required. Define the measures in context.

Can an AI service be partly unavailable?

Yes. Some functions or users may be affected while others continue working.

Is a maintenance window automatically excluded?

Only if the applicable measurement definition excludes it. State such exclusions explicitly.

AI Glossary / Governance, ethics and safety / Beginner

Availability

Definition

Availability is the property of information or a service being accessible and usable by authorized users when needed, within an acceptable time. For AI systems, it concerns the functioning service and its dependencies, not just whether a model file or web page exists.

What it means

An assistant may display a working chat window but be unable to retrieve documents, generate a response or complete an authorized action. From the user's perspective, the required service is unavailable even though part of the application is still running.

Availability is one part of the confidentiality, integrity and availability framework used in information security. Keeping a service accessible does not mean granting access to everyone. Authorization remains relevant: blocking an unauthorized request is not automatically an availability failure.

The term also differs from answer quality. A quickly delivered but incorrect explanation may meet a narrowly defined technical response measure while failing a separate quality requirement. Teams need explicit definitions so that a favorable uptime figure does not hide an unusable workflow.

How it works

Teams first define the user operation being measured and the conditions under which it counts as successful. For a search assistant, that might mean completing an eligible search and returning a usable result within a stated response time. The measurement window, excluded requests and relevant user population must be specified.

They then collect evidence from the service and, where appropriate, observations outside its own infrastructure. A healthy model server cannot report every failure in a user's network path or login service. Partial failures may affect only one region, account type or capability.

Availability can be measured as time meeting a condition or as the fraction of eligible requests completed successfully. Those measures need not agree, especially when traffic varies. Operational design may include redundancy, capacity management, tested recovery and a limited fallback mode. The aim is to preserve the needed function under defined conditions, not simply keep every component powered on.

Three practical examples

A document assistant cannot answer authorized users because the identity service is unavailable, despite healthy model servers.
A translation service remains technically reachable but takes longer than the application's permitted response time during a traffic surge.
A support application preserves access to a reviewed help catalog while its generative component is recovering, clearly identifying the reduced functionality.

Think of it this way

Think of a library that has unlocked its front door but cannot locate or issue any books. The building is open, yet the visitor's intended service is unavailable.

The analogy stops short of equating all delays with an outage. Acceptable waiting time and required functions depend on the service agreement and purpose. An overnight research task and an interactive customer response can have very different availability requirements.

Worked example

Two measurements of one outage

Suppose a fictional service operates throughout a 24-hour day and has one complete outage lasting 15 minutes. Under a simple time-based measure, availability is (1,440 − 15) / 1,440, approximately 98.96%.

That day, users make 100,000 eligible requests. The outage occurs during a busy period, causing 4,000 requests to fail; the other 96,000 succeed within the agreed time. Request-based availability is therefore 96%.

Both calculations can be correct because their denominators describe different things. Reporting 98.96% without explaining the measurement could understate the share of affected requests. The example assumes each request is counted once and all other requests succeed. Real measurement must decide how to handle retries, partial responses and requests whose failure prevents them from reaching the server's own logs.

Illustrative case study

Fictional Maple Travel measures its AI help service by checking whether a status endpoint responds. During a document-store outage, the status check remains green, but customers cannot obtain booking-policy answers.

The team adds an end-to-end check that exercises the needed retrieval path and monitors user-visible failures separately. It supplies a clearly marked link to the maintained policy catalog while the assistant is degraded. It also tests recovery instead of assuming a backup document store is ready merely because one has been configured.

The case shows that component health and service availability answer different questions. The fallback preserves a useful function but does not justify claiming that the full assistant continued operating normally.

Common misconceptions and mistakes

Uptime means every user can complete every task. A single component or average can hide partial failures.
Backups alone provide high availability. Restoring them may take time, and other dependencies may still fail.
A successful network response proves the service worked. Empty, incomplete or excessively late responses may fail the defined user requirement.
Availability means unrestricted access. It concerns usable access for the appropriate users.

Business use

Availability planning starts with the business operation that depends on AI. Identify the delay or interruption the operation can tolerate, then examine the complete dependency chain. A vendor's model-service promise may not cover your retrieval database, permissions system or integration code.

Choose measures that reflect user impact and review the consequences of degraded modes. A fallback should make its limitations clear and retain required access controls. Assess the cost of higher availability against the actual need; a universal percentage chosen without context can create expensive complexity while overlooking the most important failure path.

Check your understanding

A chatbot's home page loads, but every authorized document question fails because its retrieval database is down. Is the question-answering service available?

Answer: No, under a definition requiring successful document answers. The page and model component may be healthy while the user operation is unavailable.

Related terms

Reliability
Resilience
Latency
Fault tolerance
Integrity
service-level objective
disaster recovery
confidentiality

Learn next

Read service-level objective and resilience. Write one user operation your AI service must complete, the acceptable response time and the dependencies needed. Decide how you would detect a failure from the user's perspective.

Resilience

Sources

NIST CSRC, Availability: https://csrc.nist.gov/glossary/term/availability. Google, Site Reliability Engineering, Service Level Objectives: https://sre.google/sre-book/service-level-objectives/. These support the access and measurement concepts. The outage calculations and travel-service case are original illustrations, not vendor commitments.

Previous: Auxiliary variable Markov chain Monte Carlo Next: Availability Heuristic Bias