Inspiration
The inspiration behind QuakeGuard: Real-Time Disaster Alarm and Emergency Response System came from the need for faster communication during earthquakes and disaster situations. During emergencies, people often panic, alerts may arrive late, and it becomes difficult to know who is safe and who needs help.
We wanted to build a system that could quickly warn users, play a loud emergency alarm, display important disaster information, and allow users to respond with their safety status. The goal was to create a simple but useful disaster response platform that can help individuals, families, schools, offices, and communities react faster during emergencies.
What it does
QuakeGuard is a real-time disaster alarm and emergency response web application. When an earthquake or disaster alert is sent from the backend, the user dashboard receives the message instantly through a WebSocket connection.
The system displays the emergency alert with important details such as:
Disaster message Risk level Magnitude Current alert status User response status
When a high-risk emergency alert arrives, the system automatically triggers an alarm sound to get the user’s attention. The user can then respond quickly by choosing one of the emergency response options:
I am Safe I’m Not Safe I Need Help
The system also supports OTP-based login, stores authentication tokens, shows emergency contact numbers, and sends the user’s emergency response and location data to the backend.
How we built it
We built QuakeGuard using a full-stack web architecture.
For the frontend, we used React.js with Vite to create a fast and responsive user interface. The dashboard was designed to show real-time emergency status, alert details, emergency response buttons, and contact numbers. We used React state, context, and local storage to manage user authentication, alert status, and emergency response data.
For the backend, we used FastAPI to handle authentication, OTP verification, alert broadcasting, emergency response submission, and API communication. We used WebSocket to send real-time disaster alerts from the backend to the frontend without needing the user to refresh the page.
We used PostgreSQL as the database to store users, alerts, responses, and authentication-related data. The authentication system uses OTP login and JWT tokens for secure access.
The emergency alarm system was built using the browser’s Web Audio API. When an alert arrives, the system creates an alarm tone using audio oscillators. Because mobile browsers often block automatic audio, we also added audio unlocking during user interaction, such as login or OTP button clicks.
A simplified flow of the system is:
Admin/Backend sends alert ↓ FastAPI broadcasts alert through WebSocket ↓ React dashboard receives alert instantly ↓ Emergency modal appears ↓ Alarm sound starts ↓ User selects safety response ↓ Response and location are sent to backend
Challenges we ran into
One major challenge was making the system work properly on both laptop and mobile devices.
Accomplishments that we're proud of
We are proud that QuakeGuard can receive emergency alerts in real time and immediately display them to users. The system does not depend on manual refreshing, which makes it useful during urgent situations.
We are also proud of building a complete emergency response workflow where users can report whether they are safe, not safe, or need help. This makes the project more than just an alert system; it becomes a response tracking tool.
Another accomplishment is making the application mobile-friendly. Since emergencies can happen anywhere, it was important that users could access the system from a phone. We also improved the alarm system so it works more reliably on mobile devices.
What we learned
While building QuakeGuard, we learned how important real-time communication is in emergency systems. We gained practical experience with WebSocket connections, FastAPI backend routes, React state management, and frontend-backend integration.
We also learned about the difference between running an app on a laptop and testing it on a phone. Network configuration, IP addresses, CORS, and browser security rules can affect how an application behaves across devices.
Another important lesson was about mobile browser audio restrictions. We learned that emergency alarm systems must account for browser autoplay policies, especially on phones.
Overall, this project helped us understand how software can be used for real-world safety and emergency communication.
What's next for QuakeGuard: Real-Time Disaster Alarm
In the future, we want to improve QuakeGuard by adding more advanced disaster monitoring and response features.
Possible future improvements include:
Push notifications for alerts even when the app is closed Admin dashboard for sending alerts and viewing user responses Live map showing users who need help SMS alert support for users without internet access Multi-disaster support for earthquakes, floods, landslides, and fires Better location tracking during emergency response Offline emergency instructions
Log in or sign up for Devpost to join the conversation.