Business Continuity & Disaster Recovery
Last updated: August 2026 · v1.0
In short
Bookify Malta is a small platform operated by a small team. We do not have a dedicated data-centre, a 24/7 operations centre, or redundant physical infrastructure — those are provided by Google Cloud. This page explains what we control, what Google controls, and how we plan to keep your salon running when things go wrong.
1. What must keep running
These are the services that matter most to your salon:
| Service | Criticality | Depends on |
|---|---|---|
| Client booking page | Critical | Firebase Hosting, Firestore |
| Dashboard (calendar, approve/reject) | Critical | Firebase Hosting, Firestore, Auth |
| SMS reminders | High | Cloud Functions, Cloud Tasks, SMS relay (DigitalOcean), Epic Malta |
| Transactional email | Medium | SiteGround SMTP |
| Marketing website | Low | Firebase Hosting |
2. Infrastructure resilience (Google Cloud)
Bookify relies on Google Cloud for hosting, database, authentication, and serverless compute. Google provides:
- Redundant power, cooling, and networking at the physical data-centre level
- Automatic failover for Firestore within the selected region
- Firebase Authentication with 99.95% SLA
- Global CDN for Firebase Hosting
We cannot control a Google Cloud region-wide outage. If Google Cloud experiences a major disruption, our recovery depends on Google restoring service. During such an event, we communicate through our Status Page and direct email to affected salons.
3. Backups and data recovery
- What is backed up: All Firestore data — accounts, bookings, clients, services, settings, logs, and invoices.
- Frequency:Daily exports through Google Cloud’s managed export service.
- Retention: 30-day rolling window. Older backups are automatically overwritten.
- Restore procedure: In the event of data corruption or loss, we restore from the most recent clean backup. Restoration has been tested but we do not yet publish a formal Recovery Time Objective (RTO) or Recovery Point Objective (RPO). Our operational target is to restore core service within 24 hours of deciding to restore.
- Backup security: Backups are stored within Google Cloud and are subject to the same access controls and encryption as production data.
4. How we handle specific disruptions
Firebase / Firestore outage
If Firebase experiences a regional outage, the booking page and dashboard will be unavailable. We monitor Google’s status dashboard, post updates on our status page, and restore service as soon as Google resolves the incident. This is our single biggest dependency and the scenario most likely to cause visible downtime.
SMS outage (relay or Epic Malta)
If the messaging relay (hosted on DigitalOcean in Frankfurt) or Epic Communications cannot deliver SMS reminders, scheduled reminders will fail. We are alerted to delivery failures and will notify affected salons. Bookings remain in place — a failed reminder does not cancel an appointment. We do not currently have a backup SMS provider or relay.
Email delivery failure (SiteGround)
If SiteGround’s SMTP service is unavailable, transactional emails (password resets, notifications, invoices) will be delayed. We queue and retry where possible. Password-reset emails are the most time-sensitive; during an email outage, we can manually assist with account access.
Operator unavailability
Bookify is operated by a small team. If the primary operator is unavailable for an extended period (illness, emergency), incident response may be slower than our stated targets. We acknowledge this as a risk inherent in a small business and are working on documented handover procedures and escalation contacts.
Credential compromise
If production credentials (Firebase admin, Google Cloud service account) are compromised, we immediately rotate all keys, revoke affected sessions, audit recent access logs for unauthorised activity, and notify affected salons if their data was accessed.
Internet outage (Malta)
If the operator loses internet connectivity, the platform itself remains online (hosted on Google Cloud), but incident response and support will be delayed until connectivity is restored. We rely on mobile data as a fallback where available.
Data corruption
In the event of accidental or malicious data corruption, we restore the affected data from the most recent clean backup. Some recent data (created after the last backup) may be lost. We assess on a case-by-case basis whether partial recovery of recent data is possible through Firestore’s point-in-time recovery or transaction logs.
5. Recovery priorities
In any disruption, we restore services in this order:
- Authentication: Salons and staff must be able to log in.
- Booking pages: Clients must be able to request appointments. A salon that cannot receive bookings is losing business.
- Dashboard: Salon owners must be able to view their calendar and manage bookings.
- SMS reminders: Once the core booking flow is restored, we re-enable reminders.
- Email and support: Non-critical services are restored last.
6. How we communicate during an incident
- Status page: bookify.mt/status is updated as soon as we confirm an incident. We post updates as the situation evolves and a final summary when it is resolved.
- Direct email: For incidents affecting specific salons (e.g. a data breach), we email the account owner directly.
- Support channels: During a major incident, our support phone and email remain available, though response times may be slower than usual.
7. Honest limitations
- We do not have a secondary hosting region or multi-region failover. If the Google Cloud EU region experiences a major outage, Bookify will be unavailable until Google resolves it.
- We do not have a backup SMS provider or relay. If the DigitalOcean-hosted relay or Epic Malta cannot deliver messages, reminders will not be sent until their service is restored.
- We do not have 24/7 staffing. Outside Maltese business hours, incident response relies on the operator being reachable.
- We do not publish formal RTO or RPO commitments. Our recovery targets are operational estimates, not contractual guarantees.
This page will be updated as our resilience programme matures.
8. Testing
We test our backup restoration process periodically. We review this business continuity plan at least annually and after any significant change to our infrastructure or subprocessor arrangements. We do not currently conduct full disaster-recovery drills involving a simulated total outage.