Uptime and reliability
How Booked stays up, and what happens when a dependency does not.
Booked runs on managed cloud infrastructure with automatic failover for the web and database layers. There is no uptime SLA on the current plans — the Terms are explicit about that (Terms, section 7) — but the operational target is 99.9% availability outside scheduled maintenance.
What can degrade
Booked depends on external providers for card processing (Stripe), email (Resend), and SMS (a licensed gateway). Outages at those providers can affect the parts of Booked that use them:
| If this is down | This still works |
|---|---|
| Stripe | Bookings without deposits still complete; deposit-required bookings pause |
| Email gateway | Bookings still complete; confirmation emails queue for later delivery |
| SMS gateway | Bookings still complete; SMS reminders retry on the next window |
The principle behind that table
Taking the booking is the thing that must not fail. Every dependency is arranged so that a failure downstream of the booking — a message, a receipt — degrades into a delay rather than a lost appointment. The one exception is a deposit, because a booking that was supposed to take money and did not is worse than no booking.
What an outage does not do
It does not lose a booking that was already confirmed, and it does not double-book one. Availability is decided in the database inside the same transaction that writes the booking, so an interruption either commits the whole booking or none of it.
Data durability
Database backups are managed by the hosting layer with point-in-time recovery. In practice this means data loss is measured in seconds even in a worst-case region failure.
If something is wrong right now
Email hello@booked.co with "URGENT" in the subject and the shop URL. A live booking problem is prioritised over everything else — see Support and response times.