Skip to main content

DPPSP Recovery Objectives (RTO / RPO)

v1.0.0Compliance: May 17, 2026Edit: May 17, 2026

Recovery-time and recovery-point commitments for QRabl as a DPP Service Provider. Addendum to the platform SLA.

QRabl — DPPSP Recovery Objectives (RTO / RPO)

Scope: Recovery-time and recovery-point commitments for QRabl as a DPP Service Provider.

Relationship to the platform SLA: This document is a recovery-objective addendum to the platform SLA, which covers availability targets (99.5% uptime), response-time budgets, data retention, data residency, incident severity definitions, and service-credit remedies. That document remains authoritative for those concerns. This document adds the RTO and RPO layer that regulators and enterprise customers require under DPPSP audit (Phase 8, Appendix A.18). If a provision here conflicts with the platform SLA, the more specific document for the relevant subject matter prevails.

§1 — Definitions

Term Definition
RTO Recovery Time Objective — the maximum acceptable duration from the moment of a confirmed failure to the moment the affected surface is restored to operational status.
RPO Recovery Point Objective — the maximum acceptable age of data that can be lost in a failure scenario. An RPO of 1 hour means that in the worst case, up to 1 hour of data written before the failure may not be recoverable.
DPP API The publicly accessible Digital Product Passport endpoints: GET /api/v1/dpp/*, GET /01/{gs1_dl}, GET /s/{code}, POST /api/v1/epcis/capture, GET /api/v1/epcis/query, and the /.well-known/dppdata discovery endpoint. These are the consumer-facing and regulator-facing paths.
Analytics Scan analytics pipeline: scan_events, qr_analytics, dpp_access_audit, Umami event ingestion, and dashboard analytics queries. These surfaces are non-blocking for DPP reads; a consumer can still verify a DPP while analytics are degraded.
Non-essential Operator dashboard UI, admin tooling, billing interfaces, tenant management, label designer, translation pipeline, and cron jobs outside the DPP read path. Degradation here does not affect publicly accessible DPPs.

§2 — Commitments

Surface What's included (see §1) RTO RPO
DPP API DPP read path, GS1 Digital Link resolver, EPCIS query, well-known endpoints 4 hours 1 hour
Analytics Scan event ingestion, analytics pipeline, dashboard analytics 24 hours 24 hours
Non-essential Dashboard UI, admin tooling, operator management, billing, cron 72 hours 24 hours

Notification SLA:

  • Incident posted to https://status.qrabl.eu within 15 minutes of confirmed regression (SEV1/SEV2).
  • Root-cause analysis published within 5 business days of incident resolution.

§3 — Current vs Target — Honest Disclosure

The numbers in §2 are targets that the current infrastructure is designed to support. They become firm commitments once verified by a backup-restore drill under load.

Condition Status
Backup existence verified ✅ Hetzner Object Storage + Bunny.net Storage (Phase 12.9.5)
Cross-region replication active ✅ (Phase 12.9.5)
Full restore drill completed ⏳ Pending — first drill scheduled as part of Phase 12.9.5 operational runbook
RTO 4h confirmed by drill ⏳ Pending drill results
RPO 1h confirmed by WAL/backup cadence audit ⏳ Pending drill results

Until the first drill produces measured results, the 4h DPP API RTO and 1h RPO should be read as design targets. If the drill reveals that restore takes longer than 4 hours end-to-end, this document will be updated before the next quarterly review with honest measured numbers.

Operators who require a guaranteed (not target) RTO should contact sla@qrabl.eu to discuss an Enterprise SLA with explicit contractual backstops.

§4 — What Is NOT Covered

This document does not commit recovery objectives for:

  • Regional cloud-provider outages. If Hetzner Frankfurt experiences an outage affecting wq-apps-01 and wq-data-01 simultaneously, QRabl's ability to restore within the stated RTO depends on cross-region failover availability — which is a best-effort, not a guaranteed, path at current infrastructure scale.
  • Third-party DNS failures. If Cloudflare DNS or the tenant's DNS provider fails, QRabl cannot control resolution time.
  • Tenant-side misconfiguration. Custom-domain operators who misconfigure CNAME records or TLS certificates are outside the SLA boundary.
  • Force majeure. War, natural disaster, government orders, or events outside QRabl's reasonable control.
  • Beta / preview surfaces. Endpoints explicitly documented as non-SLA (marked in API docs with X-QRabl-SLA: best-effort).
  • Supabase internal services. Auth, Realtime, and Storage subsystems hosted on the self-hosted Supabase stack have their own recovery posture. QRabl's RTO assumptions include Supabase restart time but not Supabase data corruption.

§5 — Notification SLA

When a SEV1 or SEV2 incident is confirmed (see §6 of the platform SLA for severity definitions):

  1. Within 15 minutes: Incident posted on https://status.qrabl.eu (to be provisioned in Phase 12.10.9) with affected surface, start time, and initial impact assessment.
  2. During incident: Updates at minimum every 60 minutes while SEV1 is active.
  3. On resolution: Resolution notice posted within 30 minutes of service restoration.
  4. Within 5 business days: Root-cause analysis (RCA) published on the status page and emailed to affected Enterprise tenants.

Enterprise tenants can additionally configure webhook notifications for status page events via the dashboard (roadmap: Phase 12.10).

§6 — Cross-References

Topic Link
Platform SLA (availability, retention, residency, remedies) Platform SLA
Status page (to be built) Phase 12.10.9 — https://status.qrabl.eu
Machine-readable advertisement GET /.well-known/dppdata → service_level block

The machine-readable service_level block in the DPPSP discovery endpoint (/.well-known/dppdata) advertises the RTO/RPO numbers and links to this document so consuming systems (regulators, enterprise buyers, automated compliance tools) can discover the platform's recovery posture without reading prose documentation.

§7 — Review Cadence

This document is reviewed quarterly. First scheduled review: 2026-08-17.

Material changes — any reduction in RTO, RPO, or notification windows — require:

  1. Update to this document + the platform SLA.
  2. 30-day advance notice to Enterprise tenants via email.
  3. Update to the /.well-known/dppdata machine-readable block.

Questions? Contact sla@qrabl.eu.