# What evidence should support a software provider’s reliability promises?

By Sean Everett · October 6, 2026

Define the service behavior that matters, distinguish response from recovery, and examine whether restoration has been demonstrated under relevant conditions.

Topics: Reliability · Technology diligence · Service operations

## Translate the promise into something measurable

An availability percentage is incomplete without its scope. Ask which customer operations it covers, how failures are counted, where measurement occurs and which time window is used. A working server can coexist with an unusable customer journey.

Google’s SRE guidance distinguishes an observed service indicator, a target for that indicator and an agreement with consequences. Keep those concepts separate when reading a proposal. A target expresses the intended service level; operating records show whether it was achieved.

Compare the outward promise with the dependencies needed to deliver it. Include identity, network access, data stores and external services where relevant. Identify who handles a failure that crosses these boundaries and what the customer can expect during it.

## Give response and recovery separate clocks

An acknowledged incident, an available workaround and restored service are different milestones. Specify the event that starts and stops each clock. Otherwise two teams can report that a commitment was met while describing different outcomes.

NIST’s contingency-planning guide for federal information systems distinguishes recovery time from the point to which data must be recovered. The concepts are useful review questions: how long can the relevant operation be unavailable, and how much recent work could be lost?

Connect those answers to the actual business process. Restoring infrastructure may leave data checks, integrations or queued work unfinished. Ask when the customer can safely resume the task, with the required information present and correct. Choose objectives with the people who own that process.

## Inspect a demonstrated restoration

Request evidence from a representative recovery exercise: the starting failure, system scope, data restored, elapsed steps and unresolved problems. Compare the tested arrangement with today’s production dependencies and data volume. An old test may leave important changes unexamined.

Google’s data-integrity guidance emphasizes exercising the full recovery path, including the validity of backups and resources needed to restore them. A backup job’s success is useful evidence of one step, but does not show the complete service can be recovered.

Agree on owners and follow-up checks for gaps the exercise reveals. Preserve the distinction between a planned fix and a verified improvement. The assurance comes from clear commitments, observable service behavior and recovery practice that stays aligned with the system as it changes.

## Related reading

- [Google SRE: Service level objectives](https://sre.google/sre-book/service-level-objectives/)
- [NIST: Contingency planning and recovery objectives](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf)
- [Google SRE: Testing data recovery](https://sre.google/sre-book/data-integrity/)
- [Distinguishing prototype, beta and production readiness](https://evergences.com/insights/release-readiness-prototype-beta-production/)

Source: https://evergences.com/insights/software-reliability-recovery-evidence/