Availability management
Public content explains service ownership and the contractual boundary; numeric availability is not invented.
CHECKID · SERVICE OPERATIONS
CheckID Service Operations
A trusted identity service is more than functioning software; relying organisations need a clear operating model for change, incidents, support, continuity and API lifecycle.
SERVICEPurpose → Method → Result
TRUSTSource → Evidence → Scope
OPERATIONSSaaS · API · SDK · SLA
SERVICE OPERATIONS
Operational trust = governance + visibility + responsibility
Availability · incident · maintenance · change · support · continuity
Incident management
An incident model identifies affected service, communication path, recovery state and evidence; severity/response times follow approved process only.
Maintenance
Planned maintenance requires a communication/change path; no fictitious maintenance window is published.
API lifecycle
Versioning, deprecation, breaking changes and migration connect Developer documentation with service governance.
Support & escalation
Developer support, production incidents and security reporting are separate paths; channels/response times are published only when sourced.
Continuity
HA/DR/backup/failover claims follow architecture/NFR evidence; where contract-bound, the public page describes responsibility and the governing document.
OPERATIONAL TRANSPARENCY
Regulated customers need to know which operational information is disclosed
Public principles + contractual service levels.
| Event | Information | Boundary |
|---|---|---|
| API change | Version/release/deprecation information | Do not invent a breaking-change policy |
| Production incident | Affected service + communication + recovery | Response target per support agreement |
| Security event | Security reporting/investigation path | Separate from ordinary support |
| Scheduled maintenance | Planned change communication | Do not invent schedules |
| Continuity | Service recovery responsibility | RTO/RPO per contract/NFR |