Incident management for a major motorsport event

At a large event held at a racetrack, an electrical or hydraulic failure calls for a fast, coordinated response. When the warning travels through loose channels such as radio and phone, nobody sees the whole picture: several people report the same incident, the crew loses time finding the exact spot, and afterward there is no data on response times.

The system replaces those channels with a single board that updates instantly, where every incident is opened, followed and closed with a complete audit trail.

An installable web app (a PWA), used on phones by field staff, and a board for the operations center. With it, a person can:

• log an incident in a few taps, with name and time filled in automatically and the area suggested from the details set up in advance;
• choose the category (electrical or hydraulic), pick the type of problem from a list, set the urgency (high, medium or low) and attach up to three photos;
• log even without a connection, leaving the sending to the app once the network returns;
• follow every incident on a live board with six columns, one per status;
• dispatch the technical team, change an incident’s urgency and track first-response and resolution deadlines;
• receive a merge suggestion when two incidents look like the same one;
• close in two steps: the team resolves and records what was done, and the general coordinator validates;
• consult reports by status, urgency, area and category.

Alerts arrive as app notifications and by email. An extended configuration adds WhatsApp, SMS, a reinforced alert that repeats until it is confirmed inside the app, an interactive map, video and a seven-section daily executive report.

Offline. With no connection, the app keeps the incident on the device, marked “awaiting sync”, and sends it automatically when the network returns, as long as the app is open. On receipt, the operations center confirms to the requester “received by the center”, with the incident number. The number’s prefix shows the category (EL- or HI-), numbering is a single sequence, and the category does not change after registration.

Location. Each incident is tied to an area. Location uses fixed points on the racetrack plan, registered before the event, with no dependence on GPS or network signal.

Life cycle. An incident passes through six statuses: unattended, in triage, in progress, pending, resolved and closed. Whoever logs an incident does not close it, and whoever resolves does not validate. A resolved incident is closed only when the general coordinator validates it, and the coordinator can reopen it with a reason.

Deadlines. Each urgency level has a first-response deadline and a resolution deadline, the same for both categories. When the center changes an incident’s urgency, deadlines are recalculated from the moment it was opened, and the clock does not restart.

Real time. The board is updated through Server-Sent Events. Every status change goes through a single write point, which checks permission against the contract, records the event and, in the same transaction, emits a PostgreSQL notification that wakes the other modules. Each notification is stored before it is sent and, if the failure is temporary, is resent at increasing intervals.

Security. Each user has a personal account, with a password change at first login and a limit on login attempts, and passwords are hashed with argon2id. Name, phone and email are used only to run the event.

The system was split into independent modules, such as registration, synchronization, board, notifications and reports, built on a shared contract written in code. The contract holds the enumerations, the state machine, the deadline rules, the synchronization schemas, the events and the notifications. Each module’s plan may change only that module’s own folder.

The API specification and the frontend types are generated from this contract, and continuous integration rejects any change that leaves them out of step. Operations that take more than two seconds run in the background: the API answers with status 202 (accepted) and the app shows a processing notice.

To test the system before go-live, a rehearsal kit simulates a network drop, a backend restart with notifications in flight, and a backup restore. For production, the system is packaged as three containers: PostgreSQL 16, the FastAPI backend and a Caddy server that serves the app with automatic TLS.

The system distinguishes five roles:

• registered general user, who logs and follows the incidents they opened;
• area coordinator, who logs and follows those of their areas;
• technical team, who receive assignments and log arrival, progress and solution;
• technical manager at the operations center, who handles triage, dispatch and changes of urgency;
• general coordinator, who validates closure and decides on duplicates.

The system was made to order, not as an off-the-shelf product. It is fully developed and not yet delivered. The documentation includes a user manual, an administrator manual and a go-live runbook. The limits are documented: on iPhone, notifications require the app on the Home Screen; technician actions need a network; and a record made by mistake is not canceled but closed by the operations center.