REQVERA
The Impossible Answer · Decision note 01

How to answer a 100% availability requirement

Illustrative situation · Not a customer case
The buyer’s question

Can you guarantee 100% service availability?

Do not turn a reliability target into a zero-outage guarantee. State the approved commitment for the buyer's actual service boundary; if 100% is mandatory and non-negotiable, a qualified answer does not make the offer compliant.

A response to adapt

We cannot guarantee uninterrupted availability under every circumstance. For [named service, deployment and covered functions], we offer [approved availability commitment] measured over [measurement window] using [agreed measurement method], subject to [specific exclusions in the proposed terms]. The remedies for a shortfall are [approved remedies and contract reference]. Our proposal includes [verified resilience and recovery measures], with their scope and test evidence identified in [evidence references]. Recovery commitments are stated separately in [approved recovery terms]; they are not a promise of zero downtime. Please confirm through [authorized clarification channel] whether this defined commitment is acceptable for requirement [ID], or whether an unqualified 100% guarantee is a condition of eligibility.

Replace every bracketed field with verified facts. Remove any optional sentence you cannot substantiate. Do not submit this wording unchanged.

The availability commitment sheet

Before a percentage enters the response, reconcile these five items. A mismatch is a question for engineering and commercial approval, not a sentence to smooth over.

What counts as failure?
Specify the failed user operation, outage threshold and measurement point. A status page reporting infrastructure health cannot by itself prove successful end-to-end buyer transactions.
Over what period?
Write the time window and timezone. Distinguish time-based uptime from successful-request ratios; the same percentage can describe materially different user experience.
What is excluded?
Identify maintenance, dependency failures and customer responsibilities explicitly. Confirm whether the buyer allows those exclusions rather than copying your standard contract unchanged.
What can you demonstrate?
Match deployment architecture, monitoring coverage and recovery tests to this opportunity. Mark a promised future configuration as proposed, not already operational.
What happens if you miss?
Record the negotiated consequence and claim procedure. Service credits, termination rights and financial exposure need approval; the proposal writer does not choose them.

What makes the wording defensible

Separate an absolute uptime promise from a measurable service commitment. Define the boundary, the evidence and the exception before answering.

  • Define the service the buyer will actually use

    Name the production deployment, covered transactions, operating hours and monitoring boundary. A healthy server is not necessarily a usable application. Decide whether login, integrations, background processing and buyer-managed connectivity are included. Do not narrow the requirement silently: every material exclusion belongs in the response and proposed terms.

  • Keep four different promises separate

    A design target, measured historical availability, contractual SLA and recovery objective answer different questions. Historical results describe a period; an SLA describes an approved obligation and remedy. Recovery time and recovery point objectives concern restoration and data loss. None substitutes automatically for continuous availability.

  • An upstream SLA is not your application SLA

    A cloud provider's commitment applies to its defined service and qualifying architecture, not automatically to your entire customer journey. AWS's Compute SLA, for example, distinguishes region-level and instance-level commitments with exclusions and credit rules. Use that as a boundary-check example, not as proof of your product's reliability.

The evidence to obtain

  • Approved service terms

    Obtain the exact SLA version, measurement definition, exclusions, remedy and document precedence. Record engineering and legal approval for departures from the standard offer. Leave the percentage unfilled until this exists.

  • Comparable operating evidence

    Request monitoring data for the offered service boundary, the reporting period and known gaps. Separate observed performance from guaranteed performance. Include relevant incidents rather than selecting only the cleanest month.

  • Tested continuity arrangements

    Obtain the current deployment diagram, dependency inventory and dated recovery or failover results. Confirm what was tested, which failures were simulated and whether buyer-side actions are needed.

The decision to approve

Decision owners
Engineering or the service owner confirms feasibility; legal and the commercial authority approve the obligation. The Bid Manager records the eligibility decision and preserves the qualification.
Proceed
Proceed with a qualified response only when the offered commitment is supported, approved and permitted by the buyer's instructions or an authoritative clarification.
Do not proceed
Do not answer Yes if it means accepting an unsupported zero-outage guarantee. If the requirement is mandatory and the buyer rejects alternatives, retain the gap and escalate the bid decision.
Escalate
Ask the buyer to distinguish an availability target, contractual commitment and continuity requirement. Follow the permitted questions process; do not rely on an informal reassurance outside it.

Keep the decision in the final files

Before release, ensure the final answer preserves the approved service boundary, percentage and exclusions, and cites the correct SLA revision. REQVERA is a final-control layer for requirements, responses, approved evidence and submission files—not an uptime guarantor or a tool for negotiating exceptions.

See the authentic final-control workflow

Scope & primary references

Illustrative buyer question, not a reported customer case. General bid-response practice for availability commitments; no REQVERA SLA or product capability is asserted. Contract enforceability and mandatory tender conditions require the relevant legal and procurement review.

  • Google SRE: Service Level Objectives

    Primary engineering reference distinguishing indicators, objectives and agreements, and cautioning against absolute availability targets. Not a current Google product SLA.

  • Amazon Compute Service Level Agreement

    Provider-specific example of architecture-dependent commitments, definitions, exclusions and remedies. It does not establish the responding supplier's SLA.