Uber’s Emergency Button and The Technologies Behind It

Uber’s Emergency Button and The Technologies Behind It

Safety has long been a top priority at Uber, as Uber’s CEO Dara Khosrowshahi wrote in ‘Raising the Bar on Safety’ in September 2018. In order to #StandForSafety, the team at Uber has rolled out a set of features, such as Safety Center, Trusted Contacts, and the in-app Emergency Button, among others.

The first version of Emergency Button was rolled out in India in 2015. The original system allowed riders and drivers to contact the local police authority while remaining inside the app, and automatically alerted regional support teams to proactively reach out to the user. In 2018, the team took the opportunity to improve the system with enhanced features, such as surfacing live location information in the app, sharing trip details with authorities, and making Emergency Button available on both the Rider and Driver apps in global markets. Since then, the team has made additional enhancements in select markets by introducing the ability for users to discreetly text local police instead of a call-only option. Also, in select markets we have launched an interactive voice response solution to provide follow-up to our users.

How Does it Work?

Riders and drivers can access the Safety Toolkit by tapping the shield icon on their app’s map screen. 

Figure 1: How to use the Rider In-app Emergency Button

After tapping the Emergency Assistance feature, you will see your GPS location, car make and model, and license plate. If you Swipe To Call 911 and connect to an emergency dispatcher, those trip details become available to them digitally in many US and Mexico cities, and can be used to facilitate an emergency response. Uber’s support team will follow up with a check-in to make sure you are safe.                                  

        Emergency assistance Sheet on Driver                               Emergency assistance Sheet on Rider

Figure 2: Rider and Driver view of Emergency Button

In emergencies, seconds count. It’s important to ensure that people have the right information (real-time location and trip information) at the right time, so that they can share it with authorities quickly. It would be even more helpful if trip information and real-time locations were shared with authorities like 911 centers automatically.

911 Communications Technology

Accurate Address Info (Reverse Geocoding)

Reverse geocoding is the technology that converts a GPS location (latitude and longitude) to a readable address or place. On the Emergency Button screen, the mobile client calls the backend reverse geocoding API at a regular cadence to display the current location in the app.

Figure 3. Mobile client constantly calls reverse geocoding API to display current location address

By showing the current location, the Emergency Button makes it easy for users to communicate accurate, real-time information to 911 dispatchers, so that they are able to provide help quickly.

RapidSOS Integration and Continuous Locations Sharing

Location information is critical for emergencies. According to the Wall Street Journal, “U.S. regulators estimate as many as 10,000 lives could be saved each year if the 911 emergency dispatching system were able to get to callers one minute faster. Better technology would be especially helpful, regulators say, when a caller can’t speak or identify his or her location.”1 The Emergency Button wants to do more than help people just communicate their location verbally. In the world of the internet, we want to make real-time location and trip data visible to 911 centers automatically.

To achieve this, the team partnered with third party RapidSOS, which provides potentially life-saving data from millions of connected devices directly to 911 and first responders in an emergency2. The Emergency Button integrates with RapidSOS’ Emergency APIs and makes trip information (car’s make, model, license plate, and requester’s name) and real-time location updates available to 911 first responders. 

1 Wall Street Journal: Why Uber Can Find You but 911 Can’t  2 RapidSOS product overview

Figure 4: Emergency Service receives streamed real-time location updates and forward to RapidSOS by calling RapidSOS APIs

When someone taps the emergency button in the app, the mobile client makes a request to the Emergency backend service through a gateway proxy. Emergency Service then delivers trip data to the RapidSOS API. At the same time, the location worker on the mobile client collects and uploads location data to location services every few seconds. These real-time location updates are streamed to the Emergency Service through Kafka. Emergency Service makes HTTP requests to RapidSOS’ Location API continuously to deliver real-time location data. We take users’ privacy seriously, and so the system strictly respects users’ permission to share trip and location information with third parties, such as RapidSOS and the authorities.

This NBC segment from Washington D.C. highlights how this integration helped resolve an emergency event in the real world. Currently, the RapidSOS integration is available in around 1,200 markets, which covers over 74% trips in the US, as well as several cities in Mexico. The team is continuing to work on expanding this feature to more and more regions in the US and globally.

Leveraging SMS to 911 Centers

After releasing the functionality for calling the police inside the app, the team was looking to extend the Emergency Button’s reach even further by providing the option to send SMS to first responders. This will provide a way for people to contact emergency authorities discreetly if they do not feel comfortable talking out loud on the phone.                           

Figure 5: Text 911 button directs users to Message App with prefilled text such as car make and model, current location, and 911 as receipt

The Text 911 option will lead users to the Native Messaging App on their phones with a prefilled message with vital context for first responders, such as current location and the vehicle’s make and model. Alongside this, the mobile client creates an incident ticket for the same emergency in the Uber ecosystem to allow our team to follow-up and check-in on a user, as when a user leverages Swipe To Call. RapidSOS integration and continuous location sharing functionality are available in this flow as well.

The team built these additional features to modernize 911 communications and help make both riders and drivers feel safe on Uber’s platform. To support this, we need to build a reliable system with close to no downtime and high SLAs.

Emergency System

The emergency system’s traffic is relatively low, with typically less than one Emergency Button interaction per second. Reliability is both the most important aspect to achieve and the system’s primary technical challenge, as this is for emergencies and people’s lives can be at stake.

Multiple Alert Channels and Separation of Concerns

Each set of actions taken to process the emergency for one specific domain or integration is considered its own channel. For example, RapidSOS integration (send trip and location information to RapidSOS APIs) is one alert channel, Uber internal support (creating emergency tickets) is another alert channel. The system is built in a modular structure for multiple alert channels, instead of monolithically executing everything in a whole.

Each alert channel is decoupled with others and has its own responsibility. If a certain alert channel is broken, it thus has minimal impact on the whole emergency handling process and no impact on other alert channels. Having a modular structure also makes the emergency system flexible for updating existing or integrating new alert channels.

Figure 6: Emergency Service executes each alert channel with separate concerns and uses Kafka APIs with DLQ mechanisms

Reliable Reprocessing and DLQs with Apache Kafka®

Alert channels are implemented using tech stacks, with an emphasis on redundancy and resiliency. Uber’s Kafka team has developed internal Kafka APIs on top of Apache Kafka with which Uber’s internal service can integrate to produce and consume Kafka events. The Kafka APIs provide an at-least-once delivery guarantee: a Kafka event will be delivered to its consumer at least once—in other words, no data loss. Also, consumers can enable DLQ (Dead Letter Queue) functionality for a Kafka topic.

The internal Kafka APIs are a good fit to enhance the reliability for the Emergency Service to achieve reliable processing. For each alert channel, Emergency Service produces to and consumes from a specific Kafka topic by way of Kafka APIs. RPCs to downstream dependencies are handled in the consumer handler, and Emergency Service will return ACK (success) or NACK (failure) to the Kafka API. For any type of retryable errors returned by server errors from Emergency Service or internet failure, it translates to NACK for the Kafka server. The Kafka server will keep reprocessing the event for a configured number of retries. If after all retries the Kafka event still cannot be processed successfully, the event will be pushed to the DLQ. Messages stored in DLQ can be purged if they are bad messages or merged (reprocessed by consumer) once the system is recovered.

At-least-once delivery and the DLQ mechanism help Emergency Service to be fault-tolerant, with no data loss and the ability to quickly reprocess during a recovery.

Redundancy is Key

There could always be some unexpected errors in any system, and the Emergency Service is built with layers of redundancies and backups for every RPC or Messaging (Kafka) to make the best effort possible in processing an emergency request.

Each RPC is implemented with retries that exponentially back off. In the case that Kafka APIs are not available, the Emergency Service falls back to make RPC calls to downstreams, with a certain number of retries as a graceful degradation.

Other Alert Channels

Proactive Outreach and In-App Messaging

One of the most important alert channels for us is Uber customer support. In the event of a user-triggered emergency, the Emergency Service creates a ticket for Uber’s internal Incident Response Team (IRT). Uber IRT is a team of agents that proactively monitors incoming emergency tickets and follows up with our users to ensure their safety.

Users may be reached by phone calls, in-app help messages, or emails after they tap the Emergency Button. The emergency system also triggers in-app messaging to users, which links to the help page where they can directly report issues to Uber agents.

Interactive Voice Response

In 2019, the team built a new alert channel, Interactive Voice Response (IVR), that helps reach out to users who tap the Emergency Button. IVR contacts users by making an automated phone call. Users who receive the phone call will have options to let us know they are safe, connect to Uber support agents, etc.

This automation flow improves the efficiency of our support team, reduces false positives where the Emergency Button is touched by mistake, and also improves the system’s scalability for reaching more users.

The Interactive Voice Response alert channel executes a long workflow with multiple activities. We do not want to interfere in users’ communications with 911 first responders, so the phone call to users made by IVR is triggered 20 minutes after they tap the Emergency Button. The alert channel then executes different activities, based on their replies.

Each is managed by Uber’s Open Source Orchestration Tool, Cadence and integrated with vendor Twilio.

What’s Next?

The team continues working to actively improve Uber’s emergency services by expanding our RapidSOS integration, Text 911 feature, and interactive voice response solution to our own users around the globe. In addition, the team is leveraging this technology such that third-party vendors operating in different parts of the world will also be able to integrate with Uber, extending the ability to share live location and details with emergency services to riders and drivers everywhere.

Apache®, Apache Kafka®, and Kafka® are either registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. No endorsement by The Apache Software Foundation is implied by the use of these marks.