Operations & SLA

How Valyd runs the service in production: availability, status, incident communication, maintenance, and support. The one thing this page states with certainty is the support diagnostic contract — the X-Request-Id header documented in Errors & troubleshooting. A contractual SLA with committed availability figures is available for enterprise plans — contact your Valyd account team. Nothing on this page is itself a contractual commitment.

In Status & reliability

• Disaster recovery — backups, RPO/RTO, and failover posture.
• Support & escalation — support channels, hours, and how to escalate an incident.

Availability

Incident communication

Maintenance

Degraded-dependency behavior

When an upstream dependency (the verification engine, a face-match service, or a registry) is unreachable, Valyd surfaces it as a machine-readable error rather than a silent failure — retry with backoff. These are the documented signals from the error catalog:

• engine_unreachable (503) — the verification engine did not respond; retry.
• face_match_unavailable (502) / liveness_unavailable (502) — the selfie could not be checked right now; retry.
• 5xx in general — Valyd-side; retry with backoff, and if it persists, contact support.

Formal degraded-mode behavior and failover targets (RTO / RPO) are covered on Disaster recovery and, for enterprise plans, in the contractual SLA — contact your Valyd account team.

Support & escalation

Every Valyd response carries an X-Request-Id header. When you contact support, include:

• the X-Request-Id header value,
• the session / event id if relevant,
• a timestamp, and
• the endpoint you called.

Never send API keys, tokens, or the person’s identity data — support will never ask for them. This is the exact guidance from Errors & troubleshooting.

See also

• Trust Center
• Rate limits
• Errors & troubleshooting