Service Level Expectations
Document owner: SH Proptech Limited
Effective date: 28 February 2026 | Version 1.0
This document sets out service level expectations ("expectations"), not contractual guarantees. These expectations describe the level of service Adema aims to deliver. They do not create binding SLA obligations, service credits, or compensation rights. Enterprise customers with Order Forms may have contractual SLAs that override this document.
| Key point | Summary |
|---|---|
| Nature of this document | Service level expectations, not a contractual SLA for standard users. |
| Uptime target | We target 99.5% monthly uptime for the web platform and API. |
| Support response | Response times are target-based by severity and plan; enterprise response targets are governed by Order Form SLAs. |
| Maintenance windows | Routine maintenance is scheduled Tuesday 02:00-04:00 UTC, with major updates announced in advance where possible. |
| Incident communications | Active incidents are communicated on the status page, with post-mortems for P1/P2 incidents. |
| Enterprise priority | If an Order Form includes SLA terms, those terms override this baseline document. |
1.1. This document applies to all access tiers (Free, Token, Subscription) unless stated otherwise.
1.2. Enterprise customers with Order Forms: if your Order Form includes a Service Level Agreement (SLA), the SLA governs and this document is for reference only.
1.3. The Free Tier is provided on an "as available" basis. While we aim to meet the expectations below, Free Tier users have no service level commitments.
We aim for 99.5% monthly uptime for the Platform (web application and API), measured as: ((Total minutes in month − Downtime minutes) ÷ Total minutes in month) × 100.
| Counts as downtime | Does NOT count as downtime |
|---|---|
| Platform inaccessible to all users for >5 consecutive minutes | Scheduled maintenance (clause 3) |
| Core features (AI queries, reports, Token ledger) unavailable | Third-party service outages beyond our control (e.g., AWS region failure, AI model provider downtime) |
| API returning 5xx errors for >5 consecutive minutes | Internet connectivity issues on the user's side |
| Login/authentication system unavailable | Degraded performance that does not prevent feature use |
| Issues affecting a single user due to their account or device |
Real-time and historical availability is published at status.adema.ai. Users can subscribe to incident notifications via email or RSS.
Routine maintenance is scheduled during low-usage periods:
| Window | Timing | Expected duration | Notice |
|---|---|---|---|
| Weekly maintenance | Tuesday 02:00-04:00 UTC | Typically <30 minutes | Permanent schedule (no per-event notice) |
| Major updates | As needed, same window preferred | Up to 2 hours | 48 hours' advance notice via status page and email |
| Emergency patches | As needed (any time) | As short as possible | Retrospective notice within 24 hours |
We aim to deploy updates with zero downtime (rolling deployments). Where downtime is unavoidable, it is limited to the maintenance window and communicated in advance.
| Channel | Availability | Access tiers |
|---|---|---|
| Email (support@adema.ai) | Monday-Friday, 09:00-18:00 UK time | All tiers |
| In-app chat | Monday-Friday, 09:00-18:00 UK time | Subscription and Enterprise |
| Priority support | Extended hours per Order Form | Enterprise (Order Form) |
These are targets, not guarantees. Response time = time from ticket creation to first substantive human response (not an auto-acknowledgment).
| Severity | Description | Free Tier target | Token / Subscription target | Enterprise target |
|---|---|---|---|---|
| Critical (P1) | Platform completely unavailable or data loss occurring | Best effort | 4 business hours | 1 hour (per SLA) |
| High (P2) | Major feature broken, no workaround | Best effort | 8 business hours | 4 business hours |
| Medium (P3) | Feature degraded, workaround available | Best effort | 2 business days | 1 business day |
| Low (P4) | Minor issue, cosmetic, feature request | Best effort | 5 business days | 3 business days |
We assign severity based on impact and urgency. You may request a severity upgrade if you believe your issue has been misclassified. Severity is reviewed on a best-effort basis.
| Stage | Action | Timing |
|---|---|---|
| Detection | Incident identified (monitoring alert or user report) | As soon as possible |
| Acknowledgment | Status page updated to "Investigating" | Within 15 minutes of detection |
| Updates | Regular status updates during active incident | Every 30 minutes (P1) or every 2 hours (P2) |
| Resolution | Status page updated to "Resolved" | When service is restored |
| Post-mortem | Root cause analysis published (for P1/P2 incidents) | Within 5 business days of resolution |
For Critical and High severity incidents, we publish a post-mortem including: timeline, root cause, impact summary, remediation steps, and preventive measures. Post-mortems are published on the status page.
| Metric | Target | Notes |
|---|---|---|
| Web page load time | <3 seconds (p95) | Measured from UK-based test locations |
| AI query response | <30 seconds (typical), <120 seconds (complex) | Depends on query complexity and AI model |
| API response (non-AI endpoints) | <500ms (p95) | Standard CRUD operations |
| Report generation | <60 seconds (standard), <5 minutes (comprehensive) | Depends on report scope |
| Token balance update | Real-time (within 2 seconds of consumption) |
Performance targets are indicative. Actual performance depends on query complexity, data volume, concurrent load, and third-party dependencies.
7.1. We maintain automated daily backups of all user data and the Token ledger.
7.2. Backups are stored in a separate geographic region from the primary infrastructure.
7.3. We target a Recovery Point Objective (RPO) of 24 hours and a Recovery Time Objective (RTO) of 4 hours for disaster recovery.
7.4. These are operational targets, not contractual guarantees. Enterprise customers may negotiate binding RPO/RTO in their Order Form.
These expectations do not apply to:
9.1. This document does not create contractual service credits, refund rights, or compensation entitlements.
9.2. If we consistently fail to meet the expectations in this document, you may raise the issue through our complaints process (ToS clause 14.10).
9.3. Enterprise customers with SLAs in their Order Forms have contractual remedies as specified in those SLAs (which may include service credits).
9.4. If you believe prolonged service failures amount to a material breach of the Terms of Service, you may exercise your termination rights under ToS clause 10.
We may update this document at any time. Material changes (to uptime targets, support hours, or response times) will be notified with 30 days' notice. The effective date above indicates the latest revision.
End of Adema Service Level Expectations (v1.0, 28 February 2026)