Skip to main content
A platform that works only in a carefully staged demo is not yet a dependable service. Reliability requires explicit service objectives, monitoring, recovery plans, and honest communication.

​
15.1 Service health

Track availability, latency percentiles, request failures, queue depth, model errors, connector failures, and resource saturation. Metrics should be segmented carefully enough to locate problems without exposing sensitive customer information.

​
15.2 Graceful degradation

When a model or connector becomes unavailable, the platform should explain what is affected and avoid pretending the operation succeeded. Where safe and supported, it may offer a fallback model or a retry. Fallback behavior must respect privacy settings, model constraints, and user expectations.

​
15.3 Backups and recovery

Backups should be encrypted, access-controlled, and tested through restoration exercises. A backup that has never been restored is an optimistic file with excellent public relations.

​
15.4 Change management

Deployments should include validation, staged rollout where appropriate, monitoring, and rollback procedures. Database changes require particular care because reverting application code does not necessarily reverse a destructive schema migration.

​
15.5 Status communication

A status page or equivalent communication channel should distinguish confirmed incidents from investigations. Updates should describe impact, current mitigation, and resolution status without exposing security-sensitive details.