Orb Outage History

Customers may have experienced elevated API latencies from ~08:00–09:00Z and ~13:05–13:45Z, with some mild degradation in the timeframe in between. We've identified and mitigated the problematic underlying resource contention, and will continue to monitor. Note that this did not affect ingestion, and did not cause server-side timeouts for the vast majority of customers, but may have caused client-side timeouts.

This incident has been resolved. For customers who faced any impact because of erroneous flag evaluations, we are working directly with them on remediation and next steps.

We observed a brief (< 1 minute) period of API errors due to a database failover.

We observed processing delays and queueing between 06/07/26 00:00 UTC and 01:00 UTC, with full recovery to established baselines at 01:30 UTC. We believe this will not recur, but will continue to monitor and increase capacity to prevent this in the future. Customers with dedicated webhook SLAs and provisioning were not impacted.

This incident has been resolved.

Errors have continued to stay mitigated as of 00:33 UTC (approximately 40 mins ago).

This incident has been resolved.

This is now resolved.

We identified the root cause to be a new query that was introduced. API traffic to the affected endpoints has been healthy since the rollback at 12:55 UTC.

The vast majority of async workloads have caught up, and we will continue to monitor our services over the next few hours.

From 02/26/2026 02:16 - 02/26/2026 04:16 UTC there was a delay in event ingestion from our scheduled maintenance. This disruption may have caused delays in alerting, threshold invoices, and top-up blocks from being issued. No data-loss was experienced.

This incident has been resolved.

We have not seen any new related errors, and this incident is now resolved.

This incident has been resolved.

This incident has been resolved.

This incident has been resolved.

API latencies have returned to normal, and services are fully recovered.

As of 22:00 UTC, our revenue reporting service has caught up and is now processing data as expected.

We've spotted that something has gone wrong. We're currently investigating the issue, and will provide an update soon.

We're not seeing any continued impact on our services.

This incident has been resolved.

After ongoing monitoring, this issue is now fully resolved. Endpoints have been recovered for the last several hours; the last period of errors occurred before 05/16/25 08:30 UTC.

Due to a large increase in query volume, analytics and read queries were degraded for a time period, resulting in a brief period of API timeouts (approx. 08:19 UTC - 08:26 UTC). We apologize for the disruption, and are working to provision more capacity as a result.

From 04/07/25 07:14 to 04/07/25 15:28 UTC, customers attempting to load usage graph data for upcoming invoices in their customer portal or on the invoice portal would have encountered an error that prevented the graph from rendering. This did not impact internal views of the invoice, calculations of invoice or usage amounts, invoice issuance, or usage ingestion. The cause of this issue was a recently modified front-end component that did not properly account for data routing behavior in external portal views. The issue was resolved at 15:28am UTC.