Spare Outage History

Started Sep 30, 2026, 04:59 PM UTC· resolved Sep 30, 2026, 05:06 PM UTC

1. investigating Sep 30, 2026, 04:59 PM UTC

   We are currently investigating a temporary interruption affecting our support email contact channels. At this time, customers may experience difficulties or receive delivery failures when attempting to reach our team via [email protected] and [email protected]. Our team is actively working with our IT department to restore full email functionality as quickly as possible. In the meantime, please reach out to support through our chat channel, and we will be here to help. Thank you for your patience as we work to get this resolved.

2. resolved Sep 30, 2026, 05:06 PM UTC

   We are pleased to share that the service disruption affecting our support email channels, including [email protected] and [email protected], has been successfully resolved. Our team has worked closely with IT to restore full email functionality, meaning you can once again reach us directly via email. As our systems catch up, please note that if you sent an email to our support team yesterday, you may receive a delayed bounce-back or delivery failure message right now. If you receive one of these delayed notifications, we kindly ask that you resend your message. This will ensure we successfully receive your inquiry so we can continue collaborating and assist you without further delay. Thank you for your patience and understanding throughout this service disruption. We appreciate you bearing with us and look forward to continuing to support you.

Read the full incident report →

Started Sep 17, 2026, 02:28 PM UTC· resolved Sep 17, 2026, 04:00 PM UTC

1. investigating Sep 17, 2026, 02:28 PM UTC

   We're investigating reports that some Multimodal trip bookings fail to complete when a rider confirms a booking whose start address contains special characters. Affected riders see the following error at the confirmation step and the trip is not created: Parameter 'startAddress' must be url encoded. Its value may not contain reserved characters. It has been escalated to our engineering team and is under active investigation. We'll post an update here as we learn more.

2. identified Sep 17, 2026, 02:59 PM UTC

   We've identified the cause of the Multimodal booking errors and a fix is in progress. Some users may still encounter the error below. If you are booking a non-Multimodal trip and still see this error, refreshing your browser will clear it. Parameter 'startAddress' must be url encoded. Its value may not contain reserved characters. A fix is being deployed that fully resolves this issue for both Multimodal and non-Multimodal bookings, and no browser refresh will be required afterwards. We expect it to be live in approximately 10 minutes and will confirm here once it's out.

3. resolved Sep 17, 2026, 04:00 PM UTC

   Multimodal and non-Multimodal bookings are both fully resolved — no browser refresh is required. Our logs are healthy following the release, and the error should now be fully mitigated. If you or a rider still encounters the error below, please contact support so we can look into it. We're sorry for the disruption this caused and appreciate your patience.

Read the full incident report →

Started Sep 10, 2026, 07:13 PM UTC· resolved Sep 10, 2026, 07:51 PM UTC

1. resolved Sep 10, 2026, 08:19 PM UTC

   We have fully resolved the service disruption that impacted our AI Voice feature between 2:00 PM and 2:55 PM CST today. During this window, users may have been unable to access or utilize AI Voice services. Our Engineering team has successfully implemented a solution and monitored the system to ensure full stability. The feature is now fully recovered and operating normally. We truly appreciate your patience and understanding while we worked to restore this service.

2. postmortem Sep 17, 2026, 02:30 PM UTC

   SPARE LABS INC. CONFIDENTIAL PROPERTY # Spare Incident Report ## September 10, 2026 \(AI Voice\) ### Executive Summary On September 10, 2026, Spare's AI Voice phone service was unavailable for approximately 40 minutes, from 12:13 PM to 12:51 PM PT. Riders who called an AI Voice line were routed to the call center instead of being served by the automated voice assistant. No other parts of the platform were affected, and service was restored at 12:51 PM PT. ### Incident Details Shortly after 12:13 PM PT, callers to AI Voice lines could not establish a connection with the automated assistant and were transferred directly to the call center. We traced the failure to the maximum number of simultaneous AI Voice sessions being reached on our voice platform, which caused new call connections to be rejected. Raising that limit restored service at 12:51 PM PT. ### Cause The AI Voice service reached its session concurrency limit on our voice platform, so new call connections could not be established until the limit was increased. ### Resolution We increased the limit on simultaneous AI Voice sessions, after which calls connected normally again and the service was confirmed working. ### Timeline All times are in Pacific Time \(PT\). * 12:13 pm: AI Voice callers could no longer reach the automated assistant and were routed to the call center. * 12:44 pm: Incident declared and investigation started. * 12:51 pm: Concurrency limit raised; AI Voice service restored and verified. ### Next Steps * Adding monitoring and alerting on connection failures with our voice platform so any recurrence is detected and acted on quickly. * Reviewing AI Voice concurrency limits against expected call volumes so adequate headroom is maintained at peak. ‌ We are sorry for the disruption. Riders who use the AI Voice line expect it to answer, and on September 10 it did not for about 40 minutes. That also pushed more calls to the call center and meant some callers waited longer than they should have. We are putting the safeguards above in place so a limit like this cannot take the line down again.

Read the full incident report →

Started Aug 08, 2026, 01:03 PM UTC· resolved Aug 08, 2026, 02:53 PM UTC

1. investigating Aug 08, 2026, 01:03 PM UTC

   We are currently experiencing a service disruption affecting both the admin panel and the rider app. Users accessing these platforms may notice that performance is running significantly slower than usual. Our team is actively working with Engineering to investigate the root cause and restore normal performance levels as quickly as possible. There are currently no workarounds required, but we will share another update within 15 minutes or as soon as new information becomes available. Thank you for your patience and understanding as we work to resolve this.

2. investigating Aug 08, 2026, 01:22 PM UTC

   We are still actively investigating the service disruption affecting the admin panel and the rider app, and our team is continuing to work closely with Engineering to identify a solution. There are no new developments at this time, but we are dedicated to resolving the degraded performance as quickly as possible. We will post another update within 15 minutes or as soon as new information becomes available. We truly appreciate your continued patience and understanding.

3. investigating Aug 08, 2026, 01:37 PM UTC

   We are still actively investigating the service disruption affecting the admin panel and the rider app, and our team is continuing to work closely with Engineering to identify the cause. There are no new developments at this time, but we are fully dedicated to resolving the degraded performance as quickly as possible. We will post another update within the next 15 minutes or as soon as new information becomes available. We truly appreciate your continued patience and understanding.

4. investigating Aug 08, 2026, 01:53 PM UTC

   We are still actively investigating the service disruption affecting the admin panel and the rider app, and our team is continuing to work closely with Engineering to identify a solution. There are no new developments at this time, but we remain fully dedicated to restoring performance as quickly as possible. We will post another update within the next 15 minutes or as soon as new information becomes available. We truly appreciate your continued patience and understanding.

5. investigating Aug 08, 2026, 02:09 PM UTC

   We are still actively investigating the service disruption affecting the admin panel and the rider app, and our team is continuing to work closely with Engineering to identify a solution. There are no new developments at this time, but we remain fully dedicated to restoring performance as quickly as possible. We will post another update within the next 15 minutes or as soon as new information becomes available. We truly appreciate your continued patience and understanding.

6. identified Aug 08, 2026, 02:14 PM UTC

   We have identified the cause of the service disruption affecting the admin panel and the rider app, which was related to a backend capacity issue. Our engineering team is currently pushing forward a system update to allow application services to properly reschedule and restore capacity. Users may continue to experience degraded performance or slow load times while this fix is deployed across the infrastructure. No temporary workarounds or specific actions are required from users at this time. While we do not have an exact estimated resolution time yet, we are monitoring progress closely and will share our next update within 15 minutes. Thank you for your continued patience as we work to restore normal performance levels.

7. monitoring Aug 08, 2026, 02:20 PM UTC

   We have applied a fix, and systems have fully recovered across both the admin panel and the rider app. Both platforms are now operating normally, and response times have returned to optimal levels. Users can seamlessly access and manage their tasks as expected without taking any additional action. We will continue to monitor performance closely to ensure ongoing stability. Thank you so much for your patience and support while we worked to resolve this service disruption!

8. monitoring Aug 08, 2026, 02:36 PM UTC

   We are continuing to monitor performance closely across both the admin panel and the rider app. While systems are currently stable and showing signs of recovery, our engineering team remains actively engaged as we verify full stability across all regions. Users should no longer experience delays, but if any minor issues persist, please try refreshing your browser or restarting the app. We will post another update within the next 15 minutes to confirm full resolution. Thank you for your continued patience and support!

9. resolved Aug 08, 2026, 02:53 PM UTC

   We have successfully resolved the service disruption affecting the admin panel and the rider app, and we can confirm full system stability. Both platforms are operating normally, and performance has returned to optimal levels. You do not need to take any additional actions, such as refreshing your app or logging back in, to continue your usual tasks. Thank you so much for your patience and support throughout this service disruption. We appreciate you bearing with us while our team worked to get everything back on track!

10. postmortem Aug 10, 2026, 05:53 PM UTC

    **SPARE LABS INC. CONFIDENTIAL PROPERTY** # **Spare Incident Report** August 8, 2026 ## **Executive Summary** ‌ On Saturday, August 8, 2026, between 5:10 AM and 7:10 AM Pacific Time, organizations in our US1 data residency region experienced a critical service disruption. The admin panel loaded slowly, and in many cases windows would spin and then return a network error; the rider app was slower and less reliable over the same period. The cause was an incorrect configuration on our side: once a single availability zone had no room available, our US1 API service was prevented from adding capacity anywhere, including in zones that had capacity free. Our engineering team restored service by correcting that configuration, and the correction was rolled out to every region the same day. The platform has been healthy since. ## **Impact** ‌ Measured against customer-facing US1 API traffic: * **Errors.** 7.29% of requests returned a server error across the incident window and at 6:15 AM PT it peaked at 24.34% — roughly one request in four. * **Speed.** Average response time was 4.08s during the incident against 0.53s after recovery. * **Trip Booking impact.** Error rate alone understates the disruption, because slow and intermittently failing screens change how people work. Across the same 5:00–7:10 AM PT window on three Saturdays, successful trip creations were 4,027 on July 25 and 4,255 on August 1, against 1,775 on August 8 — a reduction of more than 50%. * **OTP Impact**: Drivers were still able to continue trip completions and navigation during the incident. Global OTP across US1 region during outage fell to 91.59%, 1.89% lower than a typical Saturday during the same time window. This was a significant degradation of service rather than a total outage. Most requests still succeeded and agencies were able to continue operating, but at materially reduced effectiveness for two hours on a Saturday morning. ## **Cause** ‌ **Underlying cause.** Our API service was configured to keep its instance counts strictly balanced across availability zones. That configuration was wrong for the way our infrastructure operates, and had been in place well before this incident \(since late 2024\) Whenever any single zone had no schedulable room, the service could not place new instances there — and the same rule then forbade placing them in the other zones, including zones with capacity sitting free. A rule intended to make the service resilient to losing a zone instead guaranteed it could not recover from ordinary capacity pressure in one. It was a latent fault waiting for an event that consumed room in a single zone. **What set it off.** A routine rollout of our routing service the previous afternoon increased the memory reserved on US infrastructure nodes, leaving one zone with no schedulable room. That rollout was ordinary and within normal operating parameters; any change that consumed room in a single zone would have produced the same result. The misconfiguration was the failure, not the rollout. **Detection.** Our support team learned of the disruption from customer calls rather than from our own alerting; Our load-balancer error alert was incorrectly defined as a cluster-scoped rule. The alert never fired, and detection fell to customer reports. Reviewing the configuration during the incident, we found two additional alert rules affected in the same way. ## **Mitigation and Resolution** ‌ At 6:55 AM PT the zone-balancing rule was corrected to allow instances to run wherever capacity was available. Existing instances did not pick up the change on their own, so the deployment was advanced manually; sixteen healthy instances came online, server errors dropped sharply, and impact ended at approximately 7:10 AM PT. Both permanent changes shipped the same day. The corrected configuration was applied to all actively maintained release branches and synchronized across every region. The load-balancer alert was converted to a global rule, validated by forcing it to fire and confirming it reached our paging system, then rolled out everywhere. The platform entered the weekend with the fix in place and with working automated detection for a recurrence. ## **Timeline** ‌ _All times are in Pacific Time \(PT\)._ * **5:10 AM** — Customer impact begins. The admin panel slows and rider app errors begin. * **5:45 AM** — Incident declared and investigation begins. * **6:15 AM** — Error rate peaks at 24.34%. New API instances are confirmed unable to be placed on any node. * **6:55 AM** — Zone-balancing rule corrected, allowing instances to be placed in zones with capacity. * **7:05 AM** — Stalled deployment advanced manually; sixteen healthy instances online. * **7:10 AM** — Customer impact ends. ## **Next Steps** ‌ * **Zone-balancing configuration corrected platform-wide** _\(Completed, August 8\)_ — All service deployments now allow placement in any zone with available capacity, so a single constrained zone can no longer prevent a service from adding capacity. * **Load-balancer alerting repaired and audited** _\(Completed, August 8\)_ — The affected alert now uses the correct rule scope and has been verified end to end in every region. We are auditing the remaining alert rules for the same class of misconfiguration. * **Review of deployment placement rules** _\(In progress\)_ — We are reviewing other aspects of our cloud topology configuration for other constraints that could similarly prevent a service from recovering. The infrastructure team will be performing a chaos engineering test in order to uncover additional risks. * **Additional alerting rules** _\(In progress\)_ — We are reviewing additional alerting policy on cluster scheduling rules with the goal of being alerted before agencies start experiencing latency issues or elevated errors. ## **Closing** ‌ We understand what two hours of a slow, unreliable platform costs an operations team on a Saturday morning, and that agencies were calling us before we knew there was a problem — which is not the standard we hold ourselves to. We take full responsibility. This was not an unusual event: it was a configuration on our side that was set up incorrectly and would have caused an outage sooner or later. It has been corrected, along with the alerting gap that let it go undetected. _If you have any questions, please reach out to our support team._

Read the full incident report →

Started May 28, 2026, 03:31 PM UTC· resolved May 28, 2026, 06:21 PM UTC

1. investigating May 28, 2026, 03:31 PM UTC

   We are currently experiencing an issue causing the AI voice feature to be unavailable. Our engineering team is actively investigating the root cause to restore full functionality as quickly as possible. We apologize for the inconvenience and will share more updates here as soon as they become available.

2. investigating May 28, 2026, 03:47 PM UTC

   While we continue looking into the AI voice issue, we have temporarily set up a forwarding rule. All calls will now be automatically redirected to the agency’s dispatch number until full functionality is restored. We will share more updates here as soon as they become available.

3. investigating May 28, 2026, 04:04 PM UTC

   Our team is still actively working on resolving the AI voice issue. We have escalated the matter and are now working directly with our service provider for a deeper review of the root cause. To ensure uninterrupted communication, the temporary workaround to redirect incoming calls directly to the agency's line is now being activated. Thank you for your continued patience. We will keep you informed here as soon as more updates come in.

4. investigating May 28, 2026, 04:05 PM UTC

   While we continue looking into the AI voice issue, we have temporarily set up a forwarding rule. All calls will now be automatically redirected to the agency’s dispatch number until full functionality is restored. We will share more updates here as soon as they become available.

5. investigating May 28, 2026, 04:28 PM UTC

   Our team is still actively working on resolving the AI voice issue. We have escalated the matter and are now working directly with our service provider for a deeper review of the root cause. To ensure uninterrupted communication, the temporary workaround to redirect incoming calls directly to the agency's line is now being activated. Thank you for your continued patience. We will keep you informed here as soon as more updates come in.

6. identified May 28, 2026, 05:16 PM UTC

   Spare has identified the root cause of the ongoing disruptions with RetailAI. The issue is originating from a third-party telephony software component (Retell / LiveKit) used within our system. The third-party provider is actively working on a fix, and they have updated their status page to track the resolution progress: https://status.retellai.com/incidents/kwgp01smx3wy Spare will continue to monitor their progress closely and will provide another update as soon as service begins to restore.

7. identified May 28, 2026, 05:36 PM UTC

   We are still awaiting further updates from our third-party provider regarding the RetailAI disruption. They are continuing to work on the underlying infrastructure issue. We will post additional information here as soon as it becomes available. Live tracking remains available here: https://status.retellai.com/incidents/kwgp01smx3wy

8. monitoring May 28, 2026, 06:03 PM UTC

   Retell has confirmed a resolution to the LiveKit outage. Spare is currently monitoring system stability closely to ensure that RetailAI service is fully restored for all users.

9. resolved May 28, 2026, 06:21 PM UTC

   We have verified that all RetailAI services are 100% stable following the third-party telephony provider's (Retell/LiveKit) resolution. All features are now fully operational. We appreciate your patience and understanding while this upstream disruption was being resolved.

Read the full incident report →

Started May 19, 2026, 11:58 PM UTC· resolved May 20, 2026, 12:34 AM UTC

1. investigating May 19, 2026, 11:58 PM UTC

   We are currently observing increased latencies across the CA region, which may result in slower-than-expected platform performance and delayed request processing. Our engineering team is actively investigating the issue and working to mitigate the impact as quickly as possible. Further updates will be shared as they become available.

2. investigating May 20, 2026, 12:13 AM UTC

   We are continuing to investigate increased latencies affecting the CA region. Users may experience intermittent command timeout errors, degraded platform performance, and delays when scheduling or managing rides. Our engineering team remains actively engaged and is working to mitigate the issue as quickly as possible. We will provide additional updates as more information becomes available.

3. monitoring May 20, 2026, 12:20 AM UTC

   A fix has been applied for the increased latencies affecting the CA region, and platform performance has shown improvement. Our engineering team is continuing to closely monitor the environment to ensure stability and confirm full recovery. We appreciate your patience while we worked through this issue.

4. resolved May 20, 2026, 12:34 AM UTC

   The incident impacting platform performance and causing increased latencies in the CA (Canada) service region has been resolved as of 17:20 PDT. Our engineering team has confirmed that services have returned to normal operation, and we will continue monitoring to ensure ongoing stability. Thank you for your patience throughout this incident.

Read the full incident report →

Started May 16, 2026, 09:08 PM UTC· resolved May 16, 2026, 10:10 PM UTC

1. investigating May 16, 2026, 09:08 PM UTC

   We are currently experiencing a service disruption affecting our platform. During this time, riders may be unable to book trips, and drivers may experience issues with vehicle location updates or accessing the Driver App. Our team continues to investigate the root cause and is working actively with Engineering to identify a solution as quickly as possible. There are no new developments or workarounds available at this time, but we are fully focused on restoring normal operations. We truly appreciate your continued patience and understanding. We will share our next update within 15 minutes, or as soon as new information becomes available.

2. investigating May 16, 2026, 09:38 PM UTC

   We continue to actively investigate the ongoing service disruption affecting our platform

3. monitoring May 16, 2026, 09:45 PM UTC

   We are glad to report that a fix has been applied, and we are seeing consistent signs of recovery across the platform. Service has been slowly restoring since approximately 2:40 PM PST, and most features are now back online. Riders and drivers should now be able to schedule trips, update vehicle locations, and access the Driver App as usual. Our team will continue to monitor system performance closely for a little longer to ensure complete stability across the network. If you are still experiencing any minor delays, please try restarting or refreshing your app. Thank you so much for your patience and support throughout this service disruption. We will post a final update once the platform is confirmed completely stable and ready to close.

4. resolved May 16, 2026, 10:10 PM UTC

   We have fully restored all services following the recent service disruption this afternoon. The disruption impacted our platform in the Canada region from approximately 1:35 PM to 2:41 PM PST, during which trip bookings, vehicle location updates, and the Driver App were affected. As of 2:44 PM PST, our engineering team has verified that all systems are completely stable and operating normally. If you continue to experience any residual lagging or minor issues, please try restarting or refreshing your app. We sincerely apologize for the inconvenience this caused to your day and truly appreciate your patience as our teams worked to resolve this as quickly as possible. This incident is now officially closed.

5. postmortem May 16, 2026, 11:32 PM UTC

   # Spare Incident Report May 16, 2026 ## Executive Summary On May 16, 2026 the Spare platform experienced a significant service disruption impacting organizations within our CA data residency region. The incident was characterized by an inability to book new trips for all customers in the CA region, from both the admin and rider interfaces, as well as driver app crashes. The disruption originated from an edit made to a geography, that resulted in corrupt data, causing our Open Street Maps based routing server to crash. Our engineering team restored service by archiving the geography causing the crashes. Errors began at low volume at 1:35 pm PT, reached outage level at 1:42 pm PT, and service was fully restored at 2:41 pm PT. ## Incident Details The errors began in low volume at 1:35 pm PT, then ramped up to high volume at 1:42 pm PT. Our Open Street Maps Routing system servers were crashing with “segmentation fault” errors, causing an inability to book new trips for all customers in the CA region, from both the admin and rider interfaces, as well as crashing driver app navigation. After trying a number of mitigations, the cause of the segmentation faults was eventually tracked down to be a corrupt customization of a geography. Spare allows customizing geographies in two manners, and older/legacy approach using external tools and uploaded changeset files, and a newer approach using an in-platform editor. Here a file generated outside of Spare with the legacy approach was uploaded, and the built routing data, when used, caused our Open Street Maps based routing server to crash. Service was restored by archiving this geography, with service partially recovering at 2:39 pm PT, and fully recovered at 2:41 pm PT. ### Cause The primary root cause was a latent issue where a bad geography could cause our routing system to crash, which had never before occurred, but then surfaced with the uploading of these geography edits. Resolution Archiving the geography that was causing the crashes. ### Timeline _All times are in Pacific Time \(PT\)._ * 1:35 pm: Errors began at low volume, minimal impact at this time * 1:42 pm: Errors reached high volume, major impact at this time * 1:45 pm: Spare on-call personnel alerted by automated alerts and investigation begins * 2:35 pm: Identified the geography causing the crashes, archived it * 2:39 pm: Partial recovery of the system * 2:41 pm: Full recovery ## Next Steps To prevent a recurrence of this failure, we’re undertaking the following: * **Temporary Disabling of “Legacy” Style Geography Edits**: Until we can fully understand all the details of the crash, we are preventing any new edits from being made to geographies using the “legacy” approach. Existing edits will remain, only new edits are disabled. * **Root Cause Analysis**: Fully understanding all the details of the crash. * **Re-Enabling “Legacy” Style Geography Edits**: Once the crashes are fully understood, and fixes put in place, we’ll re-enable “legacy” style geography edits. We recognize the critical role our platform plays in your daily operations and the significant impact this outage had on your riders, administrators and drivers. We sincerely apologize for the disruption and are committed to strengthening our infrastructure to prevent a repeat of this issue, and to consistently achieve the uptime and reliability you expect from Spare.

Read the full incident report →

Started May 15, 2026, 04:47 PM UTC· resolved May 15, 2026, 04:58 PM UTC

1. resolved May 15, 2026, 05:15 PM UTC

   A quick disruption affecting trip bookings has been addressed, and our team has successfully applied a fix. Most users who previously saw an error for ''Something unexpected went wrong, we're working on it'' message when attempting to book should now find the service is performing as expected. We are currently monitoring the platform closely to ensure continued stability and a smooth experience for everyone. If you are still seeing an error, we recommend refreshing your app or browser.

2. postmortem May 15, 2026, 11:46 PM UTC

   # Spare Incident Report May 15, 2026 ## Executive Summary On May 15, 2026 the Spare platform experienced a significant service disruption impacting organizations within our US1 data residency region. The incident was characterized by an inability to book new trips for all customers in the US1 region, from both the admin and rider interfaces, as well as degradation to driver app navigation and viewing driver routes on the live map for a more limited set of customers in the US1 region. The disruption originated from an infrastructure change to our Open Street Maps Routing system. Our engineering team restored service by reverting the infrastructure change. Errors started at 9:47 am PT, and service was fully restored to all affected organizations 11 minutes later, at 9:58 am PT. ## Incident Details The errors began at 9:47 am PT. Monitoring systems and user reports indicated greatly elevated error rates from the Open Street Maps Routing system. This caused an inability to book new trips for all customers in the US1 region, from both the admin and rider interfaces, as well as degradation to driver app navigation and viewing driver routes on the live map for a more limited set of customers in the US1 region. Specifically, users with the “Google navigation” driver app had no driver impact, but those using the “Mapbox navigation” driver app had a very elevated rate of errors when the app attempted to re-route \(driver leaving the expected route, or completing pickups/dropoffs\). An infrastructure change intended to improve how quickly the system can respond to load spikes was identified as the core cause, and this change was rolled back. The change had rolled out successfully in testing and staging environments, but failed in an unexpected way under the load of the US1 data residency region. The change was reverted and all errors stopped at 9:58 am PT. ### Cause The primary root cause was an infrastructure change to how our Open Street Maps Routing system runs and scales. The change was intended to make the system quicker to respond to load spikes, but in the US1 region failed in an unexpected way under full load, underscaling and the system could not keep up with demand, resulting in a greatly elevated error rate. Resolution Reverting the infrastructure change brought the system back to stability 11 minutes after the incident began. ### Timeline _All times are in Pacific Time \(PT\)._ * 9:47 am: Incident begins; high error rates from the Open Street Maps Routing system detected in the US1 region. * 9:56 am: Root cause identified, change reverted. * 9:58 am: Full service restored to all US1 organizations. ## Next Steps To prevent a recurrence of this failure, we’re undertaking the following: * **Root Cause Analysis**: Understand all details around the change failing in an unexpected way under load. * **Load Testing Future Similar Changes**: Identifying better ways to test similar changes under full load, and to roll out more gradually, to mitigate issues like these that occur only under full load. We recognize the critical role our platform plays in your daily operations and the significant impact this outage had on your riders, administrators and drivers. We sincerely apologize for the disruption and are committed to strengthening our infrastructure to prevent a repeat of this issue, and to consistently achieve the uptime and reliability you expect from Spare.

Read the full incident report →

Started Apr 23, 2026, 01:59 PM UTC· resolved Apr 23, 2026, 01:59 PM UTC

1. resolved Apr 23, 2026, 01:59 PM UTC

   Some agencies experienced issues entering data into the break fields, which affected all break components during manual data entry. Our engineering team identified the root cause and resolved the issue quickly; the feature should be fully operational now.

Read the full incident report →

Started Apr 16, 2026, 08:17 PM UTC· resolved Apr 16, 2026, 08:56 PM UTC

1. investigating Apr 16, 2026, 08:17 PM UTC

   We are currently experiencing a performance degradation impacting CA and US2 (Canada and United States 2) environments. Users may be unable to view or load duty schedules within the Spare Operations Demand Response Admin Platform. Our team is actively investigating the issue and will provide updates as more information becomes available.

2. investigating Apr 16, 2026, 08:32 PM UTC

   We are continuing to investigate the performance degradation impacting CA and US2 (Canada and United States 2) environments. At this time, some users may still experience issues loading the Duty Schedule page or viewing duty details, which may impact real-time operations. Our engineering team is actively working to identify the root cause and restore full functionality as quickly as possible. We’ll share further updates as soon as more information is available.

3. monitoring Apr 16, 2026, 08:46 PM UTC

   A rollback has been implemented for the CA and US2 (Canada and United States 2) environments, and system performance has improved. Users should now be able to load and view duty schedules as expected. Our team is continuing to monitor the situation closely to ensure stability.

4. resolved Apr 16, 2026, 08:56 PM UTC

   The issue impacting CA and US2 (Canada and United States 2) environments has been resolved. Users should now be able to access and view duty schedules in the Spare Operations platform as expected. Thank you for your patience while we worked to restore service.

5. postmortem Apr 17, 2026, 07:16 PM UTC

   # Spare Incident Report April 16, 2026 ## Executive Summary On April 16, 2026 at 12:50 pm PT, the Spare platform experienced a service disruption affecting customers in our CA and US2 regions. During a 52 minute window, users experienced varying degrees of system instability: * For CA Region Users: The impact was primarily limited to specific dashboard views. Most notably, users reported that the Duty Schedule page would load vehicle numbers, but driver names remained stuck in a "loading" state or appeared missing. * For US2 Region Users: In addition to the missing driver names on the Duty Schedule, users experienced slowness on numerous other pages. Key operations, including searching for riders, retrieving trip estimates, and loading payment options, were up to 10 times slower than normal. Service was fully restored to all affected organizations by 1:42 pm PT. ## Incident Details The disruption was first identified at 12:50 pm PT when internal monitoring detected extreme resource saturation on a primary database cluster. The instability manifested differently across regions due to variations in infrastructure capacity. In the US2 region, the heavy load caused several high-traffic API endpoints to experience severe latency, with response times for tasks like searching riders or updating the live map rising to between 10 and 60 seconds. ### Cause The primary root cause was a software regression introduced in a recent update to the "list duties" endpoint. * Logic Error: A refactor intended to implement a new redundancy pattern contained a bug related to the "list duties by IDs" filter. * Database Overload: When the frontend attempted to look up details for a small group of duties, the system instead attempted to count and process every duty record within the entire organization. * Resource Exhaustion: This massive, unintended data processing task created excessive database load, leading to the performance degradation observed in US2 and the loading failures in both regions. * Testing Gap: This issue was not detected during manual QA because local test environments utilized smaller datasets where the performance impact was not visible. Additionally, current automated tests did not specifically target the "list by ID" query parameter. ### Mitigation and Resolution Our engineering team implemented the following steps to stabilize the platform: * Workload Management: We temporarily disabled non-essential background tasks in the CA and US2 regions to alleviate immediate pressure on the database. * Database Optimization: The team manually executed optimization commands \(ANALYZE\) and temporarily adjusted database indexes to improve query efficiency. * Service Rollback: Once the specific cause was identified, engineering rolled back the recent API deployment in CA at 1:40 pm PT, followed immediately by US2. * Service Restoration: Full system stability was confirmed, and all background services were re-enabled by 1:42 pm PT. ### Timeline _All times are in Pacific Time \(PT\)._ * 12:50 pm: Incident begins; monitoring detects critical resource saturation in the US2 region. * 1:13 pm: Incident team responds by disabling recurring background jobs to reduce load. * 1:16 pm: Reports received from customers regarding driver names failing to load on the Duty Schedule. * 1:31 pm: Engineering initiates manual database optimization and index adjustments. * 1:40 pm: Successful API rollback in the CA region; performance begins to normalize. * 1:42 pm: API rollback completed in US2; full service restored across all affected regions. ## Next Steps To prevent a recurrence and improve platform resilience, we are taking the following actions: * Expand Test Coverage: We are updating our automated test suites to ensure that all query parameters for core API endpoints are rigorously tested for both accuracy and performance. * Infrastructure Review: We are reviewing our database tier configurations to ensure they are appropriately sized to handle unexpected workload spikes. * Advanced Monitoring: We are implementing high-urgency CPU analysis within our "canary" deployment process to detect performance regressions before they reach the general user population. We understand the critical role our platform plays in your daily operations and sincerely apologize for the frustration this disruption caused your team and your riders. We are committed to strengthening our infrastructure to deliver the reliability you expect.

Read the full incident report →

Started Apr 01, 2026, 05:30 PM UTC· resolved Apr 01, 2026, 07:15 PM UTC

1. investigating Apr 01, 2026, 05:30 PM UTC

   We are currently investigating an issue affecting access to the US1 (United States 1) Spare Admin platform. Some users may be experiencing difficulties logging in or accessing the platform. Our engineering team has identified the issue and is actively working to restore full access as quickly as possible. We will provide further updates as more information becomes available. Thank you for your patience.

2. investigating Apr 01, 2026, 05:50 PM UTC

   We are currently addressing a service disruption impacting the US1 Spare Admin platform. Helpful resources for reference: • Business Continuity Plan (BCP): https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25 • Disaster Recovery – Emergency Response Guide: https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view • Setting up Disaster Recovery Backups: https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups • Using Dispatch Backup Files: https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files We are committed to restoring full functionality promptly and will issue a follow-up once the situation is resolved.

3. investigating Apr 01, 2026, 06:00 PM UTC

   There are no updates at the moment - We are currently addressing a service disruption impacting the US1 Spare Admin platform. Helpful resources for reference: • Business Continuity Plan (BCP): https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25 • Disaster Recovery – Emergency Response Guide: https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view • Setting up Disaster Recovery Backups: https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups • Using Dispatch Backup Files: https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files We are committed to restoring full functionality promptly and will issue a follow-up once the situation is resolved.

4. investigating Apr 01, 2026, 06:15 PM UTC

   There are no updates at the moment - We are currently addressing a service disruption impacting the US1 Spare Admin platform. Helpful resources for reference: • Business Continuity Plan (BCP): https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25 • Disaster Recovery – Emergency Response Guide: https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view • Setting up Disaster Recovery Backups: https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups • Using Dispatch Backup Files: https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files We are committed to restoring full functionality promptly and will issue a follow-up once the situation is resolved.

5. monitoring Apr 01, 2026, 06:30 PM UTC

   We have applied a fix and are monitoring the Spare Admin platform following the earlier service disruption affecting the US1 environment. At this time, system performance has stabilized and we are not observing ongoing impact. Our engineering team remains engaged and is closely monitoring to ensure full recovery and prevent recurrence. We will continue to provide updates if anything changes.

6. monitoring Apr 01, 2026, 06:45 PM UTC

   We are continuing to monitor the Spare Admin platform following the earlier service disruption affecting the US1 environment. At this time, system performance has stabilized and we are not observing ongoing impact. Our engineering team remains engaged and is closely monitoring to ensure full recovery and prevent recurrence. We will continue to provide updates if anything changes.

7. monitoring Apr 01, 2026, 07:00 PM UTC

   We are continuing to monitor the Spare Admin platform following the earlier service disruption affecting the US1 environment. At this time, system performance has stabilized and we are not observing ongoing impact. Our engineering team remains engaged and is closely monitoring to ensure full recovery and prevent recurrence. We will continue to provide updates if anything changes.

8. resolved Apr 01, 2026, 07:15 PM UTC

   The issue affecting the Spare Admin platform in the US1 environment has been resolved. System performance has returned to normal levels, and users should no longer experience issues accessing the platform. Our team will continue to review this incident internally and conduct a full root cause analysis to help prevent similar disruptions in the future. If you continue to experience any issues, please don’t hesitate to reach out to our support team. Thank you for your patience while we worked to resolve this.

9. postmortem Apr 06, 2026, 04:59 PM UTC

   # Spare Incident Report April 1, 2026 ## Executive Summary On April 1, 2026, the Spare platform experienced a significant service disruption impacting organizations within our US1 data residency region. The incident was characterized by severe system latency, connection timeouts, and elevated error rates, which degraded performance and intermittent unavailability for a subset of users. The disruption originated from database congestion caused by degraded query optimization statistics, resulting in database connection pool saturation. Our engineering team restored service by manually optimizing database statistics and prioritizing critical application traffic by temporarily reducing background workload. Service was fully restored to all affected organizations by 11:35 am PT. ## Incident Details The instability began at approximately 10:30 am PT. Monitoring systems and user reports indicated that core backend services experienced degraded request processing performance resulting in widespread disruption within the US1 region. While other regions remained fully operational, organizations in US1 experienced delays, elevated error rates, and failures to connect to the platform. ### Cause The primary root cause was database connection saturation triggered by inefficient query execution. Detailed investigation identified the following technical factors: * **Stale Query Statistics**: The internal statistics used by the database to plan the most efficient way to retrieve data for Duties became out of date. * **Inefficient Indexing**: Due to these stale statistics, the system began using an inefficient index for a very high-frequency query. * **Resource Exhaustion**: This inefficient processing caused database response times to increase significantly, reaching multiple seconds, quickly exhausting the connection pool and preventing other services from communicating with the database. ### Mitigation and Resolution The engineering team implemented a multi-stage response to stabilize the environment: * **Workload Management**: We throttled recurring background jobs and disabled non-critical health checks to reduce the immediate strain on the database. * **Connection Scaling**: The database connection limit was increased by 50%, which helped stabilize conditions while the root cause was addressed until the underlying query efficiency was addressed. * **Manual Optimization**: The team executed a manual ANALYZE command on the production database. This refreshed the query statistics, allowing the database to resume using the most efficient index. * **Service Restoration**: Once statistics were updated, performance returned to normal levels, and background job throttling was gradually removed. Full restoration of service was confirmed at 11:35 am PT. During this incident, some customers utilized disaster recovery mode built into the Spare platform, which enables service continuity for rider pickups and dropoffs during outages like this one. We are aware of several customers that experienced difficulties with this mode, particularly relating to not being able to login when there were no active duties. We have identified this issue and are prioritizing a fix, with mitigation steps in place in the interim ### Timeline _All times are in Pacific Time \(PT\)._ * 10:30 am: Incident begins; severe latency and 5xx errors detected in US1 region. * 10:35 am: Status page updated; mass communications initiated to affected users. * 10:56 am: Database connection limits increased to attempt mitigation. * 11:00 am: Engineering initiates throttling of non-essential recurring jobs. * 11:22 am: Manual ANALYZE operation initiated, followed by initial signs of recovery as latency begins to drop. * 11:35 am: Full service restored to all US1 organizations. * 11:59 am: All background job throttles removed after confirming sustained stability. ## Next Steps To prevent a recurrence of this specific indexing failure, we are undertaking the following: * **Automated Statistics Refreshes**: We are implementing more aggressive and automated ANALYZE schedules for high-traffic tables \(such as the Duty table\) to ensure query plans remain optimized. * **Query Planner Tuning**: Our team is investigating adjustments to the database planner to ensure the system consistently favors more selective, efficient indexes. * **Resiliency Enhancements**: We are evaluating the implementation of circuit breakers and Redis caching for high-frequency "Duty" lookups to protect the database from total saturation if a query slows down in the future. * **Root Cause Analysis**:We are conducting a detailed root cause validation to ensure all contributing factors are addressed.. We recognize the critical role our platform plays in your daily operations and the significant impact this outage had on your drivers and riders. We sincerely apologize for the disruption and are committed to strengthening our infrastructure to prevent a repeat of this issue, and to consistently achieve the uptime and reliability you expect from Spare.

Read the full incident report →

Started Apr 01, 2026, 09:37 AM UTC· resolved Apr 01, 2026, 10:57 AM UTC

1. investigating Apr 01, 2026, 09:37 AM UTC

   We are currently investigating a service disruption affecting the admin panel, specifically concerning passenger type selections during the booking process. When attempting to change a passenger count and category (e.g., from "1 Adult" to "1 Person with Disability,") the selection may revert to "1 Adult" upon creating request. This disruption is impacting all regions and is specifically affecting dispatchers booking requests through the admin panel. Our Engineering team has confirmed this is a frontend issue and is actively working to implement a fix to ensure passenger selections are submitted correctly. While we work on a resolution, please double-check passenger details after a request is created to ensure accuracy. We are committed to restoring full functionality and will provide our next update within 15 minutes. Thank you for your patience and understanding.

2. identified Apr 01, 2026, 09:50 AM UTC

   Our Engineering team has successfully identified the root cause of the service disruption where passenger selections were reverting in the admin panel. The issue is related to a delay in how our system processes specific background updates, which prevents passenger changes from being confirmed in real-time. This delay causes a backlog that prevents certain information from saving correctly during the booking process. The impact remains the same, affecting dispatchers across all regions. Our team is now focused on addressing these processing delays to ensure all passenger data saves consistently and correctly moving forward. While we work on the resolution, please continue to verify passenger types immediately after creating a request. We do not have a specific ETA for the fix yet, but we are working with the highest priority and will share our next update in 15 minutes. Thank you for your continued patience

3. identified Apr 01, 2026, 10:11 AM UTC

   We are still actively working toward a resolution for the service disruption impacting passenger selections in the admin panel. Our Engineering team continues to address the processing delays identified earlier to ensure that all background updates and passenger data are saved consistently. There are no new developments to share at this time, but please be assured that this remains our top priority. We continue to recommend manually verifying passenger types immediately after creating a request as a temporary workaround. We truly appreciate your continued patience and will share our next update in 15 minutes or as soon as more information becomes available.

4. identified Apr 01, 2026, 10:27 AM UTC

   We are currently deploying a fix to the platform. This deployment is expected to take approximately 10-15 minutes to complete. Once the fix is fully applied, you should see immediate improvement when saving passenger selections in the admin panel. We recommend that all dispatchers refresh their browsers in about 10 minutes to ensure the update is active. We are monitoring the progress of this rollout closely and will share another update within 15 minutes. Thank you for bearing with us as we work to restore full service.

5. monitoring Apr 01, 2026, 10:45 AM UTC

   The deployment of our fix for the service disruption in the admin panel remains in progress. Our Engineering team is continuing to roll out the update across all regions, and we expect this to be completed shortly. We are keeping a close watch on the deployment to ensure that passenger selections begin saving correctly as soon as the update is live in your area. Once the rollout is complete, we recommend refreshing your browser to ensure you are seeing the most recent version of the platform. We appreciate your continued patience during this time and will share our next update in 15 minutes.

6. resolved Apr 01, 2026, 10:57 AM UTC

   The service disruption affecting passenger selections in the admin panel has been fully resolved. The fix is now active across all regions, and the system is performing normally. We have monitored the platform closely following the deployment and can confirm that passenger types are now saving correctly and consistently. If you haven't already, please refresh your browser to ensure you are using the most up-to-date version of the platform. We appreciate your patience and cooperation while we worked to address this issue. Our team remains committed to providing a reliable experience, and we are now closing this incident.

Read the full incident report →

Started Mar 26, 2026, 10:30 PM UTC· resolved Mar 26, 2026, 11:20 PM UTC

1. monitoring Mar 26, 2026, 10:30 PM UTC

   A Service Disruption within the third-party provider for Scout AI has been identified and our Engineering Team is monitoring the issue. This might result in delays or disruptions when trying to use the Scout AI Agent, we apologize for any inconveniences this might stem on your side.

2. monitoring Mar 26, 2026, 11:05 PM UTC

   An ongoing Service Disruption within the third-party provider for Scout AI is active and our Engineering Team is monitoring the issue. This might result in delays or disruptions when trying to use the Scout AI Agent, we apologize for any inconveniences this might stem on your side.

3. resolved Mar 26, 2026, 11:20 PM UTC

   The Service Disruption affecting Scout AI agent has been resolved on our third-party vendor's end. Partner Success Managers will follow up in the coming days with additional details. We apologize for any inconveniences this may have created — and appreciate your partnership & patience while we worked on this.

4. monitoring Mar 26, 2026, 11:45 PM UTC

   An ongoing Service Disruption within the third-party provider for Scout AI is active and our Engineering Team is monitoring the issue. This might result in delays or disruptions when trying to use the Scout AI Agent, we apologize for any inconveniences this might stem on your side.

Read the full incident report →

Started Mar 26, 2026, 05:34 PM UTC· resolved Mar 26, 2026, 06:22 PM UTC

1. investigating Mar 26, 2026, 05:34 PM UTC

   We are currently investigating an issue impacting platform performance. Users may experience slower response times or intermittent issues across the application. Our engineering team has identified the area of impact and is actively working to mitigate the issue. We will provide further updates as soon as more information becomes available.

2. investigating Mar 26, 2026, 05:49 PM UTC

   We are continuing to investigate the issue impacting platform performance. At this time, we have not received additional updates, but our engineering team remains actively engaged. We’ll share more information as soon as it becomes available or in the next 15 minutes.

3. monitoring Mar 26, 2026, 06:04 PM UTC

   The issue impacting platform performance has stabilized, and we are currently seeing recovery across affected services. Our team is continuing to monitor closely to ensure stability, while we conduct a root cause analysis. Further updates will be shared as more information becomes available.

4. monitoring Mar 26, 2026, 06:19 PM UTC

   The issue impacting platform performance has stabilized, and we are currently seeing recovery across affected services. Our team is continuing to monitor closely to ensure stability, while we conduct a root cause analysis. Further updates will be shared as more information becomes available.

5. resolved Mar 26, 2026, 06:22 PM UTC

   Platform performance has returned to normal, and all services are operating as expected. Our team will continue conducting a deeper root cause analysis, and Partner Success Managers will follow up in the coming days with additional details. We apologize for any inconveniences this may have created — and appreciate your partnership & patience while we worked on this.

Read the full incident report →

Started Mar 10, 2026, 04:20 PM UTC· resolved Mar 10, 2026, 05:21 PM UTC

1. monitoring Mar 10, 2026, 04:20 PM UTC

   We identified an issue causing intermittent platform latency. We will continue to monitor the environment for the next hour to ensure ongoing reliability. Thank you for your patience while we resolve this.

2. identified Mar 10, 2026, 04:35 PM UTC

   We're still investigating - We identified an issue causing intermittent platform latency. We will continue to monitor the environment for the next hour to ensure ongoing reliability. Thank you for your patience while we resolve this.

3. identified Mar 10, 2026, 04:50 PM UTC

   We're still investigating - We identified an issue causing intermittent platform latency. We will continue to monitor the environment for the next hour to ensure ongoing reliability. Thank you for your patience while we resolve this.

4. identified Mar 10, 2026, 05:15 PM UTC

   We identified an issue causing intermittent platform latency. We have since implemented a fix, and our engineering team confirms that performance has stabilized. All services are now operating within normal parameters. We will continue to monitor the environment for the next hour to ensure ongoing reliability. Thank you for your patience while we resolved this.

5. resolved Mar 10, 2026, 05:21 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 18, 2026, 06:58 PM UTC· resolved Feb 18, 2026, 07:28 PM UTC

1. investigating Feb 18, 2026, 06:58 PM UTC

   We are currently investigating an issue that is affecting trips being dispatched to Uber, causing an NDA outcome. Your organization might also see that vehicles for the Uber Open Fleet are showing an Offline status. We will provide updates in the next 15 minutes or when the Root Cause Analysis has been completed, appreciate your continued patience throughout this process.

2. monitoring Feb 18, 2026, 07:13 PM UTC

   The issue affecting trips being dispatched to Uber has seen improvements, as we observe the error messages have diminished over the last minutes. We will be actively monitoring for the next 15 minutes, appreciate your continued patience throughout this process.

3. resolved Feb 18, 2026, 07:28 PM UTC

   Thanks for your continued patience while we’ve been monitoring the Uber – Open Fleets Connector issue. At this time, we’ve observed that the errors affecting trips being dispatched to Uber have significantly diminished, and the connector behavior has stabilized. We will continue to keep an eye on performance on our end to ensure everything remains steady. Your PSM will be reaching out shortly with additional insights and any broader context regarding this incident, including follow-up details once the Root Cause Analysis is finalized. If you notice any new irregularities in the meantime, please don’t hesitate to let us know. Appreciate your partnership and time.

Read the full incident report →

Started Feb 18, 2026, 10:56 AM UTC· resolved Feb 18, 2026, 02:04 PM UTC

1. investigating Feb 18, 2026, 10:56 AM UTC

   We are currently investigating an issue where the Live Map is showing vehicles as offline for some users in the US region. Our engineering team is actively reviewing the issue to determine the cause and restore normal map functionality as quickly as possible. Trips in progress and active duties are not impacted by this issue. Please continue operations as normal, but be aware that the Live Map view may not accurately reflect vehicle locations until the issue is resolved. We will provide updates as soon as more information becomes available.

2. investigating Feb 18, 2026, 11:11 AM UTC

   We are currently investigating an issue where the Live Map is showing vehicles as offline for some users in the US region. Our engineering team is actively reviewing the issue to determine the cause and restore normal map functionality as quickly as possible. Trips in progress and active duties are not impacted by this issue. Please continue operations as normal, but be aware that the Live Map view may not accurately reflect vehicle locations until the issue is resolved. We will provide updates as soon as more information becomes available.

3. investigating Feb 18, 2026, 11:26 AM UTC

   This is still under investigation - We’re investigating reports of vehicles appearing offline on the Live Map for certain US-based users. Our engineers are on the case to restore the map view as quickly as possible. Impact: Active duties and trips are not affected, operations continue as usual, though please be aware the map may lag or show incorrect status for now. We’ll keep you posted as we learn more.

4. investigating Feb 18, 2026, 11:41 AM UTC

   This is still under investigation - We’re investigating reports of vehicles appearing offline on the Live Map for certain US-based users. Our engineers are on the case to restore the map view as quickly as possible. Impact: Active duties and trips are not affected, operations continue as usual, though please be aware the map may lag or show incorrect status for now. We’ll keep you posted as we learn more.

5. investigating Feb 18, 2026, 11:56 AM UTC

   This is still under investigation - We’re investigating reports of vehicles appearing offline on the Live Map for certain US-based users. Our engineers are on the case to restore the map view as quickly as possible. Impact: Active duties and trips are not affected, operations continue as usual, though please be aware the map may lag or show incorrect status for now. We’ll keep you posted as we learn more.

6. investigating Feb 18, 2026, 12:11 PM UTC

   This is still under investigation - We’re investigating reports of vehicles appearing offline on the Live Map for certain US-based users. Our engineers are on the case to restore the map view as quickly as possible. Impact: Active duties and trips are not affected, operations continue as usual, though please be aware the map may lag or show incorrect status for now. We’ll keep you posted as we learn more.

7. investigating Feb 18, 2026, 12:26 PM UTC

   This is still under investigation - We’re investigating reports of vehicles appearing offline on the Live Map for certain US-based users. Our engineers are on the case to restore the map view as quickly as possible. Impact: Active duties and trips are not affected, operations continue as usual, though please be aware the map may lag or show incorrect status for now. We’ll keep you posted as we learn more.

8. investigating Feb 18, 2026, 12:41 PM UTC

   This is still under investigation - We’re investigating reports of vehicles appearing offline on the Live Map for certain US-based users. Our engineers are on the case to restore the map view as quickly as possible. Impact: Active duties and trips are not affected, operations continue as usual, though please be aware the map may lag or show incorrect status for now. We’ll keep you posted as we learn more.

9. investigating Feb 18, 2026, 12:56 PM UTC

   This is still under investigation - We’re investigating reports of vehicles appearing offline on the Live Map for certain US-based users. Our engineers are on the case to restore the map view as quickly as possible. Impact: Active duties and trips are not affected, operations continue as usual, though please be aware the map may lag or show incorrect status for now. We’ll keep you posted as we learn more.

10. investigating Feb 18, 2026, 01:11 PM UTC

    This is still under investigation - We’re investigating reports of vehicles appearing offline on the Live Map for certain US-based users. Our engineers are on the case to restore the map view as quickly as possible. Impact: Active duties and trips are not affected, operations continue as usual, though please be aware the map may lag or show incorrect status for now. We’ll keep you posted as we learn more.

11. investigating Feb 18, 2026, 01:27 PM UTC

    This is still under investigation - We’re investigating reports of vehicles appearing offline on the Live Map for certain US-based users. Our engineers are on the case to restore the map view as quickly as possible. Impact: Active duties and trips are not affected, operations continue as usual, though please be aware the map may lag or show incorrect status for now. We’ll keep you posted as we learn more.

12. resolved Feb 18, 2026, 02:04 PM UTC

    Our engineers have successfully resolved the technical issue affecting the Live Map. Vehicles should now be appearing correctly and in real-time for all US-based users. Status: All systems are back to normal. Live Map: Accuracy has been restored; lagging and incorrect statuses are resolved. Operations: Continue as usual, now with full visibility. Thank you for your patience while we smoothed out the data sync. It's all up and running!

Read the full incident report →

Started Feb 04, 2026, 03:35 PM UTC· resolved Feb 04, 2026, 08:06 PM UTC

1. investigating Feb 04, 2026, 03:35 PM UTC

   We are currently investigating an issue impacting platform loading and performance for some users on the CA (Canada) region. Our engineering team is actively working to identify the root cause and restore normal service as quickly as possible. Some or all of your Spare Driver applications may be impacted by this incident. Please validate with your drivers/operators whether or not they can continue to use the Spare Driver app. If they cannot, please enact your Spare Business Continuity Plan. Here are some helpful links to get started: * Business Continuity Plan (BCP) - (https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25) * Disaster Recovery - Emergency Response Guide - (https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view) * Setting up Disaster Recovery Backups - (https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups) * Using Dispatch Backup Files - (https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files) We’ll provide updates here as we learn more. Thanks for your patience.

2. investigating Feb 04, 2026, 03:48 PM UTC

   We are continuing to investigate this issue.

3. investigating Feb 04, 2026, 03:52 PM UTC

   Our team is continuing to investigate the platform loading and performance issues reported earlier. At this time, we don’t have additional updates to share, but our engineering team remains actively engaged. Some or all of your Spare Driver applications may be impacted by this incident. Please validate with your drivers/operators whether or not they can continue to use the Spare Driver app. If they cannot, please enact your Spare Business Continuity Plan. Here are some helpful links to get started: * Business Continuity Plan (BCP) - (https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25) * Disaster Recovery - Emergency Response Guide - (https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view) * Setting up Disaster Recovery Backups - (https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups) * Using Dispatch Backup Files - (https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files) We’ll provide another update as soon as more information becomes available. Thank you for your continued patience.

4. investigating Feb 04, 2026, 03:53 PM UTC

   Our team is continuing to investigate the platform loading and performance issues reported earlier. At this time, we don’t have additional updates to share, but our engineering team remains actively engaged. Some or all of your Spare Driver applications may be impacted by this incident. Please validate with your drivers/operators whether or not they can continue to use the Spare Driver app. If they cannot, please enact your Spare Business Continuity Plan. Here are some helpful links to get started: * Business Continuity Plan (BCP) - (https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25) * Disaster Recovery - Emergency Response Guide - (https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view) * Setting up Disaster Recovery Backups - (https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups) * Using Dispatch Backup Files - (https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files) We’ll provide another update as soon as more information becomes available. Thank you for your continued patience.

5. identified Feb 04, 2026, 04:14 PM UTC

   Our engineering team has idenitfied a fix to address the platform loading and performance issues reported earlier. The fix is currently rolling out across the platform, and we are closely monitoring its progress. Some or all of your Spare Driver applications may be impacted by this incident. Please validate with your drivers/operators whether or not they can continue to use the Spare Driver app. If they cannot, please enact your Spare Business Continuity Plan. Here are some helpful links to get started: * Business Continuity Plan (BCP) - (https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25) * Disaster Recovery - Emergency Response Guide - (https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view) * Setting up Disaster Recovery Backups - (https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups) * Using Dispatch Backup Files - (https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files) We will provide another update once the rollout has completed and we can confirm platform stability. Thank you for your continued patience.

6. identified Feb 04, 2026, 04:19 PM UTC

   Our engineering team has idenitfied a fix to address the platform loading and performance issues reported earlier. The fix is currently rolling out across the platform, and we are closely monitoring its progress. Some or all of your Spare Driver applications may be impacted by this incident. Please validate with your drivers/operators whether or not they can continue to use the Spare Driver app. If they cannot, please enact your Spare Business Continuity Plan. Here are some helpful links to get started: * Business Continuity Plan (BCP) - (https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25) * Disaster Recovery - Emergency Response Guide - (https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view) * Setting up Disaster Recovery Backups - (https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups) * Using Dispatch Backup Files - (https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files) We will provide another update once the rollout has completed and we can confirm platform stability. Thank you for your continued patience.

7. identified Feb 04, 2026, 04:35 PM UTC

   We are maintaining oversight of the issue and anticipate further updates shortly - Our engineering team has idenitfied a fix to address the platform loading and performance issues reported earlier. The fix is currently rolling out across the platform, and we are closely monitoring its progress. Some or all of your Spare Driver applications may be impacted by this incident. Please validate with your drivers/operators whether or not they can continue to use the Spare Driver app. If they cannot, please enact your Spare Business Continuity Plan. Here are some helpful links to get started: * Business Continuity Plan (BCP) - (https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25) * Disaster Recovery - Emergency Response Guide - (https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view) * Setting up Disaster Recovery Backups - (https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups) * Using Dispatch Backup Files - (https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files) We will provide another update once the rollout has completed and we can confirm platform stability. Thank you for your continued patience.

8. identified Feb 04, 2026, 04:44 PM UTC

   We are continuing to work on a fix for this issue.

9. investigating Feb 04, 2026, 05:01 PM UTC

   Our engineering team deployed a fix intended to address the platform loading and performance issues reported earlier. However, we are still seeing an ongoing impact, and the issue has not been fully resolved at this time. The team is continuing to actively investigate and is working on additional remediation steps to restore full platform stability. Some or all of your Spare Driver applications may be impacted by this incident. Please validate with your drivers/operators whether or not they can continue to use the Spare Driver app. If they cannot, please enact your Spare Business Continuity Plan. Here are some helpful links to get started: * Business Continuity Plan (BCP) - (https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25) * Disaster Recovery - Emergency Response Guide - (https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view) * Setting up Disaster Recovery Backups - (https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups) * Using Dispatch Backup Files - (https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files) We’ll provide another update as soon as more information becomes available. Thank you for your continued patience.

10. investigating Feb 04, 2026, 05:10 PM UTC

    Our engineering team deployed a fix intended to address the platform loading and performance issues reported earlier. However, we are still seeing an ongoing impact, and the issue has not been fully resolved at this time. The team is continuing to actively investigate and is working on additional remediation steps to restore full platform stability. At this time, the impact remains limited to the CA region. US1 and US2 are operating normally. Some or all of your Spare Driver applications in the CA region may be impacted by this incident. Please validate with your drivers/operators whether or not they can continue to use the Spare Driver app. If they cannot, please enact your Spare Business Continuity Plan. Here are some helpful links to get started: • Business Continuity Plan (BCP) – https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25 • Disaster Recovery – Emergency Response Guide – https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view • Setting up Disaster Recovery Backups – https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups • Using Dispatch Backup Files – https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files We’ll provide another update as soon as more information becomes available. Thank you for your continued patience.

11. investigating Feb 04, 2026, 05:21 PM UTC

    Our engineering team deployed additional remediation steps to address the platform loading and performance issues reported earlier. As of 09:21 PT, the additional database capacity increase in the CA region has completed, and we are seeing a return to normal service. The team is continuing to actively monitor the platform and investigate the underlying cause to ensure continued stability. At this time, the impact remains resolved in the CA region, and US1 and US2 are operating normally. Some or all of your Spare Driver applications may have been impacted earlier today. If you enacted your Business Continuity Plan during the incident, you may begin transitioning back to normal operations as appropriate. Here are some helpful links for reference: • Business Continuity Plan (BCP) – https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25 • Disaster Recovery – Emergency Response Guide – https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view • Setting up Disaster Recovery Backups – https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups • Using Dispatch Backup Files – https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files We’ll continue to monitor closely and will provide another update if anything changes. Thank you for your patience while we worked through this.

12. monitoring Feb 04, 2026, 05:26 PM UTC

    Our engineering team deployed additional remediation steps to address the platform loading and performance issues reported earlier. As of 09:21 PT, the additional database capacity increase in the CA region has completed, and we are seeing a return to normal service. The team is continuing to actively monitor the platform and investigate the underlying cause to ensure continued stability. At this time, the impact remains resolved in the CA region, and US1 and US2 are operating normally. Some or all of your Spare Driver applications may have been impacted earlier today. If you enacted your Business Continuity Plan during the incident, you may begin transitioning back to normal operations as appropriate. Here are some helpful links for reference: • Business Continuity Plan (BCP) – https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25 • Disaster Recovery – Emergency Response Guide – https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view • Setting up Disaster Recovery Backups – https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups • Using Dispatch Backup Files – https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files We’ll continue to monitor closely and will provide another update if anything changes. Thank you for your patience while we worked through this.

13. monitoring Feb 04, 2026, 05:36 PM UTC

    A fix has been applied to address the platform loading and performance issues. As of 9:21 PM PST, our engineering team is actively monitoring the platform to confirm full recovery and stability. Some organizations may continue to experience intermittent issues while monitoring is ongoing. If you or your team encounter any problems, we recommend the following steps: - Perform a hard refresh in your browser - Close and reopen the Spare Driver app on affected devices If you enacted your Business Continuity Plan (BCP) during the incident, you may begin transitioning back to normal operations as appropriate while monitoring continues. Here are some helpful resources for reference: Business Continuity Plan (BCP): https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25Disaster Recovery – Emergency Response Guide: https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/viewSetting up Disaster Recovery Backups: https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backupsUsing Dispatch Backup Files: https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files We’ll provide another update once monitoring is complete or if additional information becomes available. Thank you for your patience.

14. monitoring Feb 04, 2026, 05:51 PM UTC

    A fix has been applied to address the platform loading and performance issues. As of 9:21 PM PST, our engineering team is actively monitoring the platform to confirm full recovery and stability. Some organizations may continue to experience intermittent issues while monitoring is ongoing. If you or your team encounter any problems, we recommend the following steps: Perform a hard refresh in your browserClose and reopen the Spare Driver app on affected devices If you enacted your Business Continuity Plan (BCP) during the incident, you may begin transitioning back to normal operations as appropriate while monitoring continues. Here are some helpful resources for reference: Business Continuity Plan (BCP): https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25Disaster Recovery – Emergency Response Guide: https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/viewSetting up Disaster Recovery Backups: https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backupsUsing Dispatch Backup Files: https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files We’ll provide another update once monitoring is complete or if additional information becomes available. Thank you for your patience.

15. resolved Feb 04, 2026, 06:06 PM UTC

    The platform loading and performance issues have been resolved. Our engineering team has confirmed system stability following continued monitoring after the fix applied earlier. At this time, all services are operating normally. If you enacted your Business Continuity Plan (BCP) during the incident, you may now fully transition back to normal operations. Your PSM will follow up directly to coordinate a post-incident review and share additional context, including findings and next steps from this incident. For reference, here are the relevant resources: Business Continuity Plan (BCP): https://www.notion.so/189e9a7769a6802185f1e65cc30d5321?pvs=25 Disaster Recovery – Emergency Response Guide: https://drive.google.com/file/d/1KXtfZy70AGhM48QElJGMvxnwqMAV3Shx/view Setting up Disaster Recovery Backups: https://help.sparelabs.com/en/articles/10134588-setting-up-disaster-recovery-backups Using Dispatch Backup Files: https://help.sparelabs.com/en/articles/10263338-using-dispatch-backup-files Thank you for your patience and partnership while we worked to resolve this issue.

16. postmortem Feb 05, 2026, 05:43 AM UTC

    # Spare Incident Report February 4, 2026 ## Executive Summary On February 4, 2026, the Spare platform experienced service disruptions primarily impacting customers served by our CA region infrastructure. Users experienced two distinct windows of instability characterized by system slowness, operation timeouts, and intermittent error messages. The disruption was caused by database resource contention following a scheduled infrastructure adjustment, compounded by a "cold cache" state and stale query optimization statistics that led to connection pool exhaustion. Our engineering team addressed the issues through immediate capacity increases, manual optimization of database statistics, and temporary suspension of non-essential background tasks to prioritize core service stability. Service was fully restored to all affected organizations by 11:14 am PT. ## Incident Details The incident occurred in two phases. The first began at 7:20 am PT when monitoring systems alerted the team to severe connection pool exhaustion in one of our database clusters. A second period of instability occurred at 10:16 am PT as the system struggled to optimize queries under peak morning load. ### **Cause** The primary root cause was the exhaustion of the database connection pool, which prevented backend services from processing queries. Our detailed investigation identified two contributing factors: * **Resource Contention**: A database scale-down operation performed the previous evening resulted in insufficient capacity to handle the surge in morning traffic. * **Stale Query Statistics**: Following the necessary scale-up to restore capacity, the database query planner lacked updated statistics \(specifically requiring a manual ANALYZE operation\). This caused the system to use inefficient query plans, leading to high disk I/O and further instances of connection pool exhaustion. ‌ ### **Mitigation and Resolution** Our team’s response focused on immediate capacity restoration and system stabilization: * **Capacity Increase**: Engineering immediately scaled the CA database back to its previous capacity tier and increased the number of API pods to distribute the load more effectively. * **Query Optimization**: To resolve the second wave of instability, the team manually executed ANALYZE commands across the database clusters to refresh statistics and restore efficient query processing. * **Workload Management**: We temporarily disabled non-critical background jobs during the incident to reduce database pressure. * **Service Restoration**: Full service was confirmed for all organizations served from our CA region by 11:14 am PT. ## Timeline _All times are in Pacific Time \(PT\)._ * 07:20 am: Monitoring detects connection pool exhaustion; Incident Team responds. * 07:26 am: Team initiates CA database scale-up to restore capacity. * 08:00 am: API pod health checks temporarily removed to reduce database load during recovery. * 09:21 am: Database scale-up completes; initial service restoration achieved. * 10:16 am: A second wave of high error rates is detected as morning load peaks. * 11:03 am: Non-essential background jobs are disabled to prioritize core platform stability. * 11:14 am: Manual database optimization \(ANALYZE\) completed; full service restored to all organizations. * 12:52 pm: Background jobs re-enabled after confirming sustained system stability. ## Next Steps To ensure continued reliability and prevent a recurrence of this resource contention, we are undertaking the following: * **Infrastructure Configuration**: We are updating our infrastructure-as-code \(Terraform\) configurations to prevent automatic down-scaling of production-critical database tiers, and to more appropriately schedule database statistic refreshes \(via ANALYZE operation\). * **Operational Procedures**: We are implementing a mandatory requirement to refresh database statistics following any manual or automated scaling event. * **Performance Monitoring**: We are enhancing our alerts for "cold cache" symptoms and disk I/O wait times to detect potential bottlenecks before they result in connection exhaustion. We understand that this disruption was more than just a technical failure; it was a breakdown in the service you and your riders depend on every day. We are deeply sorry for the immense frustration and operational strain this caused your teams. Reliability is the foundation of our partnership, and we fell short of that standard today. We are working with absolute urgency to implement the safeguards required to deliver the level of uptime performance you expect.

Read the full incident report →

Started Jan 30, 2026, 07:29 PM UTC· resolved Jan 30, 2026, 08:06 PM UTC

1. investigating Jan 30, 2026, 07:29 PM UTC

   We are currently investigating a service disruption affecting navigation services for organizations using Mapbox integration. Drivers may encounter error messages stating that "The operation couldn't be completed" or receive notifications regarding incorrectly formatted server responses. Consequently, turn-by-turn navigation is currently unavailable for these users. Our engineering team is actively working to identify the root cause of these errors and restore full navigation functionality. We understand how critical reliable navigation is for your operations and sincerely apologize for the disruption. Our team will provide another update within the next 15 minutes.

2. monitoring Jan 30, 2026, 07:44 PM UTC

   We have identified the cause of the service disruption and a fix has been successfully applied. We are now seeing signs of recovery across the platform, and navigation services for organizations using Mapbox should be returning to normal. Our team is continuing to monitor performance closely to ensure full stability. If you or your drivers continue to experience issues with navigation or error messages, please try closing and reopening the app. If the issue persists, a fresh reinstallation of the app may be required to clear any remaining errors. We will provide a final update once the incident is confirmed fully resolved. Thank you for your patience and for bearing with us throughout this process.

3. monitoring Jan 30, 2026, 07:51 PM UTC

   We have identified the cause of the service disruption and a fix has been successfully applied. We are now seeing signs of recovery across the platform, and navigation services for organizations using Mapbox should be returning to normal. Our team is continuing to monitor performance closely to ensure full stability. If you or your drivers continue to experience issues with navigation or error messages, please try closing and reopening the app. If the issue persists, a fresh reinstallation of the app may be required to clear any remaining errors. We will provide a final update once the incident is confirmed fully resolved. Thank you for your patience and for bearing with us throughout this process.

4. resolved Jan 30, 2026, 08:06 PM UTC

   The service disruption affecting navigation services for organizations using Mapbox integration has now been fully resolved. Our engineering team has confirmed that the fix was successfully applied and that navigation services are operating normally across the platform. We have continued monitoring performance and are no longer observing errors related to incorrectly formatted responses or failed navigation requests. If any drivers previously experienced issues, normal app usage should now resume without requiring further action. We sincerely apologize for the impact this disruption may have caused and appreciate your patience while our team worked to restore full functionality. If you notice any unexpected behavior, please don’t hesitate to reach out to our support team. Thank you for your continued trust.

Read the full incident report →

Started Jan 19, 2026, 02:21 PM UTC· resolved Jan 19, 2026, 02:21 PM UTC

1. resolved Jan 19, 2026, 02:21 PM UTC

   Occasional unresponsive pages and loading delays have been reported within Service Planning > Stops. We are aware that pages might have either failed to load with increased latency. The issue is now resolved. Pages are loading correctly and populating as expected without further errors.

Read the full incident report →

Started Jan 09, 2026, 07:50 PM UTC· resolved Jan 09, 2026, 09:05 PM UTC

1. investigating Jan 09, 2026, 07:50 PM UTC

   Our Support Ticketing System provider is currently experiencing a Major Service Disruption affecting all of our Customer-facing communication channels. If you happen to have any service disruption related to Spare Platform or Rider/Driver Apps, please contact us at our Outage Phone Line. We apologize for any inconveniences or delays in communication.

2. investigating Jan 09, 2026, 08:05 PM UTC

   Our Support Ticketing System provider continues to experience a Major Service Disruption, and all customer-facing communication channels remain unavailable. We are monitoring the situation closely as the provider works toward a resolution. If you experience any service disruption related to the Spare Platform or Rider/Driver Apps, please continue to contact us via our Outage Phone Line.

3. investigating Jan 09, 2026, 08:20 PM UTC

   Our Support Ticketing System provider continues to experience a Major Service Disruption, and all customer-facing communication channels remain unavailable. We are monitoring the situation closely as the provider works toward a resolution. If you experience any service disruption related to the Spare Platform or Rider/Driver Apps, please continue to contact us via our Outage Phone Line.

4. investigating Jan 09, 2026, 08:35 PM UTC

   Our Support Ticketing System provider continues to experience a Major Service Disruption, and all customer-facing communication channels remain unavailable. We are monitoring the situation closely as the provider works toward a resolution. If you experience any service disruption related to the Spare Platform or Rider/Driver Apps, please continue to contact us via our Outage Phone Line.

5. investigating Jan 09, 2026, 08:50 PM UTC

   Our Support Ticketing System provider continues to experience a Major Service Disruption, and all customer-facing communication channels remain unavailable. We are monitoring the situation closely as the provider works toward a resolution. If you experience any service disruption related to the Spare Platform or Rider/Driver Apps, please continue to contact us via our Outage Phone Line.

6. resolved Jan 09, 2026, 09:05 PM UTC

   Our Support Ticketing System is now fully back online, and all communication channels have been restored. Thank you for your patience.

Read the full incident report →

Started Jan 05, 2026, 02:22 PM UTC· resolved Jan 05, 2026, 02:56 PM UTC

1. investigating Jan 05, 2026, 02:22 PM UTC

   Our Support Ticketing System provider is currently experiencing a Major Service Disruption affecting all of our Customer-facing communication channels. If you happen to have any service disruption related to Spare Platform or Rider/Driver Apps, please contact us at our Outage Phone Line. We apologize for any inconveniences or delays in communication.

2. investigating Jan 05, 2026, 02:37 PM UTC

   Our Support Ticketing System provider continues to experience a Major Service Disruption, and all customer-facing communication channels remain unavailable. We are monitoring the situation closely as the provider works toward a resolution. If you experience any service disruption related to the Spare Platform or Rider/Driver Apps, please continue to contact us via our Outage Phone Line.

3. resolved Jan 05, 2026, 02:56 PM UTC

   Our Support Ticketing System is now fully back online, and all communication channels have been restored. Thank you for your patience.

Read the full incident report →

Started Dec 23, 2025, 04:16 PM UTC· resolved Dec 23, 2025, 04:48 PM UTC

1. investigating Dec 23, 2025, 04:16 PM UTC

   We are currently investigating a service disruption that is causing intermittent errors and slowness for all customers within the US region. This may also affect the functionality of the driver app. Our engineering team is actively working to identify the cause and restore full performance as quickly as possible. We do not have a specific timeline for resolution yet, but we are committed to sharing regular progress. We will provide another update within the next 15 minutes or as soon as more information becomes available. Thank you for your patience as we work to resolve this.

2. monitoring Dec 23, 2025, 04:35 PM UTC

   We have successfully mitigated the service disruption affecting the United States (US) region, and we are now seeing significant recovery across our systems. Most customers should experience immediate improvement in performance The issue began at 8:16AM PT and was successfully mitigated by 8:29AM PT. All systems are now stable, and features are performing as expected. If you continue to see any lingering effects, please perform a hard refresh or restart your app. We appreciate your patience while our team worked to restore service. Our team will continue to monitor the platform closely for stability before officially closing the incident. We sincerely appreciate your patience and will provide a final update once the situation is fully resolved.

3. monitoring Dec 23, 2025, 04:47 PM UTC

   The service disruption affecting the United States (US) region is now fully resolved. Between 8:16 AM and 8:29 AM PT, users may have experienced slowness, intermittent errors, or difficulties while using the driver app. Systems are now stable, and you should see immediate improvement. If you continue to experience any issues, please perform a hard refresh of your browser or app. We appreciate your patience while we worked to restore full service.

4. resolved Dec 23, 2025, 04:48 PM UTC

   The service disruption affecting the United States (US) region is now fully resolved. Between 8:16 AM and 8:29 AM PT, users may have experienced slowness, intermittent errors, or difficulties while using the driver app. Systems are now stable, and you should see immediate improvement. If you continue to experience any issues, please perform a hard refresh of your browser or app. We appreciate your patience while we worked to restore full service.

5. postmortem Dec 24, 2025, 05:43 PM UTC

   # Spare Incident Report December 24, 2025 ## Executive Summary Between December 21 and December 23, 2025, the Spare platform experienced brief service disruptions impacting the US region. Users may have experienced intermittent error messages and system slowness during several distinct time windows. The disruption was caused by resource contention within our primary database infrastructure, which led to connection pool exhaustion. This prevented backend services from successfully processing queries. Our engineering team intervened immediately during the initial event to restore service. Subsequent brief recurrences were handled by automated recovery systems while a permanent fix regarding database configuration was explored and some changes to the system were implemented. ## Incident Details The incident began on Sunday, December 21, at 8:00 am PST when internal monitoring systems alerted our engineering team to a spike in database connection errors and increased latency in the US region. ### **Cause** The primary root cause for this incident was the exhaustion of the database connection pool, preventing the platform from establishing necessary connections to the database. Upon deeper investigation, it was determined that specific database triggers were acquiring exclusive locks on key resources. This locking behavior created a bottleneck, leading to query backups and eventual exhaustion of available connections. ### **Mitigation and Resolution** Our team’s response focused on immediate service restoration, data integrity verification, and root cause elimination: 1. **Immediate Restoration:** During the initial incident, the engineering team restarted backend services to reset database connections and clear internal caches, restoring full service. 2. **Data Integrity Check:** While our priority was service restoration, we conducted a thorough review out of an abundance of caution to ensure data integrity. We confirmed that all data remained secure and accurate throughout the incident. 3. **Root Cause Elimination:** During the subsequent brief recurrences on December 22 and 23, the team gathered necessary diagnostic data to identify the problematic database triggers. These triggers have been removed to eliminate the resource locking issue and prevent recurrence. ## Timeline _All times are in Pacific Time \(PST\)._ * **Dec 21, 08:00 am:** Monitoring systems detect elevated error rates and latency in the US region. * **Dec 21, 08:03 am**: Team begins incident investigation. * **Dec 21, 09:10 am:** Service is fully restored following a restart of backend services. * **Dec 22, 05:30 am:** A recurrence of connection pool exhaustion is detected. * **Dec 22, 05:38 am:** System auto-recovers as backend services stabilize; diagnostic data is gathered. * **Dec 22, 10:15 am:** A second minor recurrence is detected. * **Dec 22, 10:21 am:** System auto-recovers and normal service resumes. * **Dec 22, 1:35 pm:** Root cause identified \(database triggers\) and implementation of fix begins. * **Dec 23, 8:16 am**: A third minor recurrence occurs. * **Dec 23, 8:29 am**: System auto-recovers and normal service resumes. * **Dec 23, 9:26 am**: Fix rolled out to all systems in all regions. ## Next Steps To ensure the continued reliability of our platform and prevent similar resource contention issues, we are undertaking the following: * **Database Optimization:** We have removed the problematic triggers and are reviewing all database locking mechanisms to ensure optimal concurrency. * **Enhanced Monitoring:** We are implementing stricter alerts regarding database connection pool usage to detect potential contention before it impacts user experience. * **Cache Resiliency:** We are reviewing our caching logic to ensure it recovers more gracefully during periods of backend instability. We appreciate your understanding as we worked through this incident. We remain vigilantly focused on continuous improvement of our system’s stability and availability.

Read the full incident report →

Started Dec 21, 2025, 04:32 PM UTC· resolved Dec 21, 2025, 05:10 PM UTC

1. investigating Dec 21, 2025, 04:32 PM UTC

   For US organizations, there are currently issues with booking trips. Our engineering team is actively investigating the cause of this problem.

2. investigating Dec 21, 2025, 04:35 PM UTC

   For US organizations, there are currently issues with booking/canceling/editing trips. Affected users would see some occasional errors in the product.

3. investigating Dec 21, 2025, 04:46 PM UTC

   We are currently investigating reports of occasional errors affecting some users in the US Region. These issues began at approximately 8:10 AM PT. Our engineering team is actively diagnosing the root cause to restore full stability. Users may experience temporary latency or intermittent failure messages while navigating the product. We will provide further updates as more information becomes available.

4. investigating Dec 21, 2025, 05:00 PM UTC

   We are currently investigating reports of occasional errors affecting some users in the US Region. These issues began at approximately 8:10 AM PT. Our engineering team is actively diagnosing the root cause to restore full stability. Users may experience temporary latency or intermittent failure messages while navigating the product. We will provide further updates as more information becomes available.

5. identified Dec 21, 2025, 05:05 PM UTC

   We have identified the cause of the intermittent errors and are currently taking corrective action. Our team is restarting specific backend services to restore stable connections to our database. We are monitoring the impact of these restarts closely. While we do not have a firm ETA for a full resolution, we expect to see service stability improve as these processes complete. Thank you for your continued patience.

6. resolved Dec 21, 2025, 05:10 PM UTC

   A fix has been implemented, and we have seen service levels return to normal as of 9:10 AM PT. We have successfully restored backend database connections, and the intermittent errors in the US region have subsided. Our engineering team will continue to monitor the system closely for the next hour to ensure continued stability. If you are still experiencing issues, please try refreshing your browser or contact our support team.

7. postmortem Dec 24, 2025, 05:52 PM UTC

   # Spare Incident Report December 24, 2025 ## Executive Summary Between December 21 and December 23, 2025, the Spare platform experienced brief service disruptions impacting the US region. Users may have experienced intermittent error messages and system slowness during several distinct time windows. The disruption was caused by resource contention within our primary database infrastructure, which led to connection pool exhaustion. This prevented backend services from successfully processing queries. Our engineering team intervened immediately during the initial event to restore service. Subsequent brief recurrences were handled by automated recovery systems while a permanent fix regarding database configuration was explored and some changes to the system were implemented. ## Incident Details The incident began on Sunday, December 21, at 8:00 am PST when internal monitoring systems alerted our engineering team to a spike in database connection errors and increased latency in the US region. ### **Cause** The primary root cause for this incident was the exhaustion of the database connection pool, preventing the platform from establishing necessary connections to the database. Upon deeper investigation, it was determined that specific database triggers were acquiring exclusive locks on key resources. This locking behavior created a bottleneck, leading to query backups and eventual exhaustion of available connections. ### **Mitigation and Resolution** Our team’s response focused on immediate service restoration, data integrity verification, and root cause elimination: 1. **Immediate Restoration:** During the initial incident, the engineering team restarted backend services to reset database connections and clear internal caches, restoring full service. 2. **Data Integrity Check:** While our priority was service restoration, we conducted a thorough review out of an abundance of caution to ensure data integrity. We confirmed that all data remained secure and accurate throughout the incident. 3. **Root Cause Elimination:** During the subsequent brief recurrences on December 22 and 23, the team gathered necessary diagnostic data to identify the problematic database triggers. These triggers have been removed to eliminate the resource locking issue and prevent recurrence. ## Timeline _All times are in Pacific Time \(PST\)._ * **Dec 21, 08:00 am:** Monitoring systems detect elevated error rates and latency in the US region. * **Dec 21, 08:03 am**: Team begins incident investigation. * **Dec 21, 09:10 am:** Service is fully restored following a restart of backend services. * **Dec 22, 05:30 am:** A recurrence of connection pool exhaustion is detected. * **Dec 22, 05:38 am:** System auto-recovers as backend services stabilize; diagnostic data is gathered. * **Dec 22, 10:15 am:** A second minor recurrence is detected. * **Dec 22, 10:21 am:** System auto-recovers and normal service resumes. * **Dec 22, 1:35 pm:** Root cause identified \(database triggers\) and implementation of fix begins. * **Dec 23, 8:16 am**: A third minor recurrence occurs. * **Dec 23, 8:29 am**: System auto-recovers and normal service resumes. * **Dec 23, 9:26 am**: Fix rolled out to all systems in all regions. ## Next Steps To ensure the continued reliability of our platform and prevent similar resource contention issues, we are undertaking the following: * **Database Optimization:** We have removed the problematic triggers and are reviewing all database locking mechanisms to ensure optimal concurrency. * **Enhanced Monitoring:** We are implementing stricter alerts regarding database connection pool usage to detect potential contention before it impacts user experience. * **Cache Resiliency:** We are reviewing our caching logic to ensure it recovers more gracefully during periods of backend instability. We appreciate your understanding as we worked through this incident. We remain vigilantly focused on continuous improvement of our system’s stability and availability.

Read the full incident report →

Started Dec 21, 2025, 04:00 PM UTC· resolved Dec 22, 2025, 05:26 PM UTC

1. resolved Dec 22, 2025, 02:09 PM UTC

   We observed a brief period of platform instability from 5:30 AM to 5:38 AM PT. During this time, some users may have encountered errors or incomplete page loads. The issue has since been resolved.

2. postmortem Dec 24, 2025, 05:51 PM UTC

   # Spare Incident Report December 24, 2025 ## Executive Summary Between December 21 and December 23, 2025, the Spare platform experienced brief service disruptions impacting the US region. Users may have experienced intermittent error messages and system slowness during several distinct time windows. The disruption was caused by resource contention within our primary database infrastructure, which led to connection pool exhaustion. This prevented backend services from successfully processing queries. Our engineering team intervened immediately during the initial event to restore service. Subsequent brief recurrences were handled by automated recovery systems while a permanent fix regarding database configuration was explored and some changes to the system were implemented. ## Incident Details The incident began on Sunday, December 21, at 8:00 am PST when internal monitoring systems alerted our engineering team to a spike in database connection errors and increased latency in the US region. ### **Cause** The primary root cause for this incident was the exhaustion of the database connection pool, preventing the platform from establishing necessary connections to the database. Upon deeper investigation, it was determined that specific database triggers were acquiring exclusive locks on key resources. This locking behavior created a bottleneck, leading to query backups and eventual exhaustion of available connections. ### **Mitigation and Resolution** Our team’s response focused on immediate service restoration, data integrity verification, and root cause elimination: 1. **Immediate Restoration:** During the initial incident, the engineering team restarted backend services to reset database connections and clear internal caches, restoring full service. 2. **Data Integrity Check:** While our priority was service restoration, we conducted a thorough review out of an abundance of caution to ensure data integrity. We confirmed that all data remained secure and accurate throughout the incident. 3. **Root Cause Elimination:** During the subsequent brief recurrences on December 22 and 23, the team gathered necessary diagnostic data to identify the problematic database triggers. These triggers have been removed to eliminate the resource locking issue and prevent recurrence. ## Timeline _All times are in Pacific Time \(PST\)._ * **Dec 21, 08:00 am:** Monitoring systems detect elevated error rates and latency in the US region. * **Dec 21, 08:03 am**: Team begins incident investigation. * **Dec 21, 09:10 am:** Service is fully restored following a restart of backend services. * **Dec 22, 05:30 am:** A recurrence of connection pool exhaustion is detected. * **Dec 22, 05:38 am:** System auto-recovers as backend services stabilize; diagnostic data is gathered. * **Dec 22, 10:15 am:** A second minor recurrence is detected. * **Dec 22, 10:21 am:** System auto-recovers and normal service resumes. * **Dec 22, 1:35 pm:** Root cause identified \(database triggers\) and implementation of fix begins. * **Dec 23, 8:16 am**: A third minor recurrence occurs. * **Dec 23, 8:29 am**: System auto-recovers and normal service resumes. * **Dec 23, 9:26 am**: Fix rolled out to all systems in all regions. ## Next Steps To ensure the continued reliability of our platform and prevent similar resource contention issues, we are undertaking the following: * **Database Optimization:** We have removed the problematic triggers and are reviewing all database locking mechanisms to ensure optimal concurrency. * **Enhanced Monitoring:** We are implementing stricter alerts regarding database connection pool usage to detect potential contention before it impacts user experience. * **Cache Resiliency:** We are reviewing our caching logic to ensure it recovers more gracefully during periods of backend instability. We appreciate your understanding as we worked through this incident. We remain vigilantly focused on continuous improvement of our system’s stability and availability.

Read the full incident report →