Skip to main content
OnArrival

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.

Illustration: a signal operator in a small railway signal box at dawn rests one hand on a tall lever and watches the line, where a column of signal lamps shows a single amber light among the clear ones.
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 .

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.

Illustration: a person writes a postcard over morning coffee at a kitchen table beside a tall window, warm sunlight falling across the table.
Stay informed
Preview incident updates by email, RSS or webhook.

Related reading

All field notes →
Technical · 11 min

What to monitor after a travel booking is confirmed

Search latency cannot tell you whether a flight changed or a refund arrived. Post-booking monitoring needs to detect supplier changes, missing updates and delays in telling the traveller.

Manan VaghasiyaOperations · 10 min

Post-booking service: who handles changes and refunds?

A confirmed booking still needs support when a flight changes, a traveller cancels or a refund is delayed. Customers need a clear status, a next step and someone responsible for the outcome.

Ankit Sawant