SLA
BizKitHub's uptime, data-durability, incident-response and service-credit commitments for the CMS, CRM, REST API and CORE services.
Scope
This SLA covers the CMS, CRM, REST API and CORE services of the BizKitHub platform and applies to every customer on the Pro tier from the date of subscription.
Effective date: July 8, 2025.
Headline commitments
- 99.90 % monthly uptime guarantee (SLO target: 99.99 %).
- 11 nines annual data durability (99.999999999 %).
- 15 minutes initial response for P1 (critical) incidents.
Key metrics defined
- Availability — percentage of time services are available in a calendar month (Monthly Uptime Percentage).
- Data Durability — probability of never losing data; currently 11 nines annually.
- RTO (Recovery Time Objective) — maximum time to restore service after an outage.
- RPO (Recovery Point Objective) — maximum data loss (in time) when restoring from backup.
- Incident — an unplanned event causing service degradation or outage.
- Scheduled maintenance — planned maintenance announced at least 48 hours in advance.
Availability calculation
Availability is measured with a standardised formula:
Uptime % = Uptime / (Total minutes − Excused Downtime) × 100Measurement methods
- BetterStack — active request monitoring from multiple regions.
- Cloudflare — edge-level health checks.
- Vercel — platform-side performance metrics.
- Interval — near-minute measurement cadence.
Status pages
- Primary: status.bizkithub.com
- Backup: status.baraja.cz
Service credits
If we miss the availability commitment we apply credits to the next invoice automatically — no customer request required.
| Monthly uptime | Service credit |
|---|---|
| < 99.9 % but ≥ 99.0 % | 10 % |
| < 99.0 % but ≥ 95.0 % | 25 % |
| < 95.0 % | 50 % |
Data retention & protection
Accidental deletion protection
Every delete operation keeps a complete copy of the data for up to 7 days — protection against human error, attacks, and enabling fast recovery.
Insider threat protection
Multi-layer access controls prevent a rogue employee from executing bulk deletions against production data.
Offline backups
Production data is backed up to a separate, undisclosed storage location: S3-compatible storage in a different data centre, end-to-end encrypted.
Incident categories
We reserve the right to determine the incident type and priority — and to revise it as an incident unfolds. AI-assisted classification may be used to speed up triage.
| Priority | Severity | Description | Impact |
|---|---|---|---|
| P1 | Critical | Complete service outage. | All users affected; all data unavailable. |
| P2 | Major | Severe incident. | Key features unavailable; limited workflows possible. |
| P3 | Minor | Moderate degradation. | Slower response times; non-critical features affected. |
| P4 | Low | Inquiries and cosmetic issues. | Documentation, UI, minor bugs not blocking usage. |
Response times
| Priority | Label | 90 % response | First action |
|---|---|---|---|
| P1 | Critical | 15 min | 2 hours |
| P2 | Major | 1 hour | 4 hours |
| P3 | Minor | 4 hours | 100 hours |
| P4 | Low | 48 hours | as agreed |
Escalation
Escalated incidents are forwarded to the internal Incident Manager first, then to the CTO if the situation is not resolved within the response window.
Monitoring & transparency
Real-time service status is available on the status pages above. Historical data — monthly availability reports, incident analyses, service performance trends, and post-mortem reports — is published there as it becomes available.
Contact
Questions about this SLA go to /support.