Availability and Support Targets
Operating objective and measurement scope; service credits only by separate agreement. Use your browser’s print command to save this complete version as PDF.
Qedara adopts an operating objective of 99.5% monthly core-service availability. It is an objective, not a service-credit SLA or a historical achievement. Customer-specific contractual adoption and any service credits require an accepted service order. The public status publishes observed coverage and gaps; earlier periods are not inferred.
1 Scope and calculation
Core service means authenticated access to existing contract records, document retrieval and the core application API with a working database. AI inference, transactional email delivery, external register checks and optional product integrations are tracked as separate components. If a dependency failure also prevents core access, that core impact counts as core downtime.
Monthly availability equals 100 × (eligible minutes minus unavailable minutes) / eligible minutes. Eligible minutes are all minutes in the UTC calendar month after measurement begins. Planned maintenance and provider-caused core outages count. At 99.5%, a 30-day month allows 216 minutes of unavailability. This is a target, not a prediction or a promise of zero loss.
Use independent external checks at 60-second intervals plus a safe synthetic access/retrieval check. Confirm failure through a second independent check or an incident record; once confirmed, count from the first failed interval. Report missing or unusable monitoring as unknown. For target assessment, unknown minutes count against availability but remain separate from confirmed downtime in the report. A month with less than 95% valid coverage is “insufficient data”, not compliant.
2 Status reporting
Publish component state, UTC update time, open incidents, maintenance and retained incident history. Keep public incident records for at least 12 months and a monthly availability report for 12 months. Publish a new month’s report within five business days. Reports distinguish measured downtime, unknown intervals and source coverage. Historical data is not backfilled from an isolated health check.
Public endpoint measurement is live at https://qcm-status.qedara.com from 19 October 2026, 08:13 UTC. One-minute external probes check the sign-in page and API/database health. The report shows partial-month coverage and unknown minutes explicitly. These probes do not yet establish authenticated contract retrieval, signing, AI or email availability. Accordingly, they must not be presented as proof of the broader core-service objective above.
3 Support and maintenance
| Item | Proposed service target |
|---|---|
| Support channel | office@qedara.com. General support Monday to Friday, 09:00–18:00 Europe/Bucharest, excluding Romanian public holidays. |
| Critical service issue | Initial acknowledgement target: four business hours during support hours. No guaranteed restoration time is offered. |
| Other service request | Initial acknowledgement target: two business days. |
| Personal data breach | The DPA’s maximum 24-hour initial notice after awareness applies independently of these support targets. |
| Planned material maintenance | Give at least 48 hours’ notice where practicable; urgent security work may require shorter notice. Record actual service impact. |
| Availability miss | Review cause, publish measured impact and provide corrective actions and owners. Automatic financial credits require a separate agreed SLA. |
4 Recovery planning
Database and attachment backups run daily, with encrypted off-host copies and hourly expiry. On 19 October 2026 an isolated restore verified the selected pair, 112 collections, 6,293 records and 72 files; stored hashes and authentication checks matched. This is a completed restore exercise, not a guarantee of future recovery time or a full customer workflow test. Internal planning objectives are a recovery point within 24 hours and restoration within eight hours after disaster recovery is invoked; no contractual RPO/RTO warranty is offered.
Customers should keep periodic exports of critical signed documents and evidence and an alternative signing or approval process for urgent transactions. The incident lead must report the actual recovery point, any unrecoverable interval and successful validation after a restore.
5 Activation and changes
Public endpoint monitoring has started; the broader authenticated core-service objective still requires a synthetic access/retrieval check, tested alert routing, an incident owner and deputy, and an accepted service order. No contractual service-credit SLA is currently offered by default. A buyer requiring such an SLA must agree its scope and remedies separately. The live status page is useful evidence of its stated endpoint scope, not a substitute for that agreement.
Coverage added in version 1.2: a dedicated synthetic viewer signs in through the ordinary authentication flow, verifies its live session and workspace membership, reads a fixed private synthetic file and signs out every five minutes. The public status shows this component separately. Its introduction does not convert the earlier one-minute public endpoint percentage into an end-to-end transaction SLA. AI, email delivery and signing completion are not independently probed.