Is Spare down?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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!

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!

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!

**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._