# System Status Reporting Preview | OnArrival > An illustrative preview of OnArrival service health reporting: supplier dependencies, incident history and notifications, on sample data only. Take a look. Source: https://www.onarrival.com/status --- # See how health will be reported. This page is a product preview built with sample data. It is not connected to OnArrival production monitoring and must not be used to assess current availability. Example surfaces 8 Sample 90-day figure 99.95% Monitoring connection Not live How to read this page ## What the colours and numbers mean. Everything below is sample data. It shows the format we intend to publish, not live service health. Three states · sample definitions - Operational Working normally. - Degraded Results are still correct, but the product is slower than its target or has dropped some non-critical supply. - Down Search, pricing or booking returns errors on more than 5% of requests over a rolling 5-minute window. One row, explained · sample 1. **State:** the product’s condition at the snapshot time. 2. **Daily bars:** one bar per day. An amber bar marks a day with issues. 3. **p99 164ms:** 99 in every 100 requests were answered faster than this. 4. **99.98% 90d:** the share of the last 90 days the product was up. Products ## By API surface. Illustrative data model. Fixed sample snapshot 09 May 2026, 00:14 UTC. Flights 517+ carriers nominal Operational p99 138ms · 99.99% 90d Hotels 2M+ properties synced Operational p99 164ms · 99.98% 90d Experiences All supply nominal Operational p99 121ms · 100.00% 90d Buses 12 operators reporting delays Degraded p99 612ms · 99.71% 90d Travel Fintech Quote-to-bind nominal Operational p99 96ms · 99.99% 90d Payments & ledger Multi-PSP failover armed Operational p99 74ms · 100.00% 90d Bundles Cross-supplier workflows OK Operational p99 209ms · 99.97% 90d API & webhooks p99 within SLO Operational p99 142ms · 99.99% 90d Suppliers ## Upstream dependencies. An example of the suppliers that can sit behind each product: hotel wholesalers (bedbanks), airline systems (GDS and NDC), payment providers (PSPs) and bus operators. Names and states below are illustrative, not current supplier health. Bedbanks · Hotels All nominal HotelBedsOK TBOOK Expedia RapidOK HotelstonOK GDS & NDC · Flights All nominal AmadeusOK SabreOK TravelportOK Direct NDCOK PSPs · Payments All nominal StripeOK AdyenOK Checkout.comOK Operators · Buses 2 affected RedBus aggregatorDelayed Regional operator pool (12)Delayed FlixBusOK National coach feedsOK This sample shows how an affected operator could be isolated while healthy supply remains available. It demonstrates the intended reporting pattern, not a current Buses incident. Illustrative SLA context ## How targets can be explained. This sample shows how tier targets, outage definitions, and credit rules can sit beside service health. It is explanatory website copy, not a service commitment; the signed MSA governs each customer. Sandbox Best-effort No uptime commitment CreditNot eligible Shared test environment for evaluation. Health is published here for transparency, but Sandbox carries no contractual target. Build 99.9% ≤ 43m 12s / month CreditUp to 10% MRR The default production commitment, mirroring the Build tier on pricing. Calculated per product on the surfaces you call, blended monthly. Enterprise 99.95%+ ≤ 21m 36s / month CreditCustom + P1 Negotiated targets, named P1 escalation, and credit schedules set in your MSA. Per-surface SLOs and a dedicated status webhook are available. How one minute counts against the target · sample rule Down minute **100%** counts in full Degraded minute **25%** counts as a quarter Announced maintenance **0%** if the booking path stays online Failover drill **0%** never counts against you Downtime What counts against the clock A surface is Down when the booking path fails closed, meaning availability, quote or bind returns errors on more than 5% of requests over a rolling 5-minute window. Down minutes are counted per affected product, not for the platform as a whole. Degraded Slow is not the same as down A surface is Degraded when results stay correct but it is slower than its latency target (p99, the slowest 1% of requests, is over the SLO) or it sheds non-critical supply, like the Buses surface above. A degraded minute counts as 25% of a full outage minute, never zero. Excluded Announced maintenance windows Time inside a maintenance window announced at least 72 hours ahead is excluded from the SLA clock, provided the booking path stays online behind it, as it did for the 03 Apr ledger rebuild. Failover drills never count against you. Credits How a miss is made right If we miss the monthly target on a product you call, a service credit is applied to that month's usage automatically and shown on your invoice. You file nothing. Our own measurement is the source of truth, and you can audit it against this page. The 99.95% figure and all 8 service rows use sample data. They do not report production uptime. Your signed order form or MSA defines service targets, measurement and credits. Example history ## A postmortem model. Illustrative incidents and maintenance windows show the level of detail intended for future reporting: blast radius, timeline, and the fix. These are sample records, not a production incident log. Export sample history (CSV) 1. **What happened?** *In each: What happened* 2. **Who was affected?** *In each: Blast radius* 3. **How fast was it fixed?** *In each: Timeline* 4. **What changed afterwards?** *In each: The fix* 2026-05-09 Hotel rates · cache lag for HotelBeds 14 min Resolved **Read the postmortem** What happened A rate-cache warm-up job for the HotelBeds bedbank fell behind after a schema migration, so a slice of availability reads served prices up to ~90 seconds stale. No bookings confirmed on a stale price. The bind-time re-quote caught every mismatch and rejected it cleanly. Blast radiusHotels surface only · ~3.1% of availability reads on the HotelBeds connector · all other bedbanks and all binds unaffected. Timeline +00:00 Cache freshness SLO (p95 age > 60s) trips; on-call paged automatically. +00:04 Stale connector quarantined; reads failed over to the secondary cache region. +00:14 Warm-up job rebuilt and re-pinned; freshness back inside SLO. Resolved. The fix Migrations now gate the warm-up job behind a readiness probe, and rate-cache age is an explicit pre-bind check rather than a background-only alarm. 2026-04-22 Flights · NDC connector retry queue 8 min Resolved **Read the postmortem** What happened One NDC carrier returned malformed pricing envelopes after a partner-side deploy. Our connector correctly rejected them, but the retry queue back-pressured and added latency to shopping calls routed through that carrier. Blast radiusFlights surface · 1 of 517+ carriers · ~0.6% of shopping requests saw added latency, no failed binds. Timeline +00:00 Connector error-rate breaches threshold; circuit half-opens. +00:02 Faulty carrier shed from the shopping pool; queue drains. +00:08 Partner envelope fixed upstream; carrier re-admitted on green health-checks. Resolved. The fix Per-carrier circuit breakers now trip on envelope-schema failures (not just timeouts), so a single partner can never back-pressure the shared retry queue. 2026-04-03 Maintenance · ledger reconcile rebuild 2 h Maintenance **Read the postmortem** What happened Planned, announced maintenance: we rebuilt the double-entry ledger reconcile indexes to cut nightly close time. Writes stayed fully online behind the write-ahead log; only the reconcile read-replica was rotated. Blast radiusNo customer-facing impact. Payments and binds processed normally throughout; settlement reporting lagged by the window and back-filled on completion. Timeline +00:00 Window opens; reconcile replica drains and detaches (announced 72h prior). +01:40 Indexes rebuilt; replica re-attaches and replays WAL. +02:00 Reconcile verified against control totals; window closes. The fix Not a failure: a scheduled change is an event, not an incident. Logged here for the same audit trail buyers use to reason about everything else. 2026-03-18 Payments · PSP failover drill 3 min Drill **Read the postmortem** What happened Scheduled game-day: we deliberately blackholed the primary PSP to prove multi-PSP failover under live traffic. Authorisation routing shifted to the secondary acquirer within the target window. Blast radiusZero declined transactions attributable to the drill. Median auth latency rose ~40ms during cutover, then recovered. Timeline +00:00 Primary PSP route severed by the drill harness. +00:11 Auth traffic re-homed to secondary acquirer; success rate holds. +03:00 Primary restored; routing rebalanced. Drill passed. The fix Failover budget confirmed under load. We run this drill quarterly so the path is proven, not assumed. 2026-02-27 Buses · operator-side outage propagation 21 min Resolved **Read the postmortem** What happened An upstream operator aggregator had a regional outage. Their availability endpoint returned 5xx, which surfaced as degraded inventory for the affected routes. The fault was entirely operator-side; our connector degraded gracefully and kept serving cached schedules where safe. Blast radiusBuses surface · routes served by 12 of 90+ operators · search still returned results from healthy operators; affected routes showed a degraded badge rather than failing. Timeline +00:00 Operator endpoint 5xx-rate breaches threshold; surface marked Degraded. +00:05 Affected operators isolated; healthy supply unaffected. +00:21 Operator recovers upstream; health-checks green; surface back to Operational. The fix Added cached-schedule fallback for read-only browse on degraded operators, and per-operator status now renders on this page (see the supplier breakdown above) so the blast radius is legible at a glance. Notification model ## Choose your channel. Preview the notification routes intended for production. Email opens a draft, RSS is a sample feed, and webhook configuration lives in the developer documentation. [Email Prepare an email asking for incident + recovery notices. Open subscription draft](mailto:hello@onarrival.travel?subject=Subscribe%20to%20OnArrival%20status%20updates&body=Subscribe%20me%20to%20status%20notifications%20for%3A%20(list%20the%20products%20you%20depend%20on).) [RSS / Atom Inspect the format planned for machine-readable updates. Open sample feed](https://www.onarrival.com/status.xml) [Webhook Read how signed status events can reach your endpoint. Read webhook docs](https://docs.onarrival.com/) Stay informed Preview incident updates by email, RSS or webhook. Choose a channel [Read the status docs](https://docs.onarrival.com/)