How It Works
A plain-English walkthrough of where Seattle Breaking's data comes from and how we display it.
The single most important thing to understand about Seattle Breaking is that we do not gather any new data. Every incident on the live feed comes from a dataset that the City of Seattle already publishes to anyone with an internet connection. Our role is to fetch it, clean it, categorize it, drop it on a map, and refresh the view every thirty seconds. That is the entire pipeline.
The two data sources
Seattle Breaking pulls from two named, public datasets hosted on the Seattle Open Data portal:
- Seattle Real Time Fire 911 Calls — every call accepted into the Seattle Fire Department's CAD system, with type, address, latitude, longitude, and dispatch timestamp. Published by the Seattle Fire Department. Hosted at data.seattle.gov.
- SPD Call Data — calls handled by the Seattle Police Department, with initial and final call types, clearance description, priority, event timestamps, and a location generalized to the police beat. Published by the Seattle Police Department. Hosted at data.seattle.gov.
Both datasets use the Socrata Open Data API, which is the standard format the City uses for its public datasets. We send a query every minute asking for the most recent two hundred events from each feed and merge them into a unified list sorted by time.
How we categorize incidents
The upstream feeds use dozens of free-text incident-type strings — things like "Aid Response", "Auto Fire Alarm", "MVI Freeway", "Suspicious Circumstances", and so on. Most readers don't want to sort through that many labels. We collapse everything into six visual categories that match the colored map pins:
- Fire — structure fires, vegetation fires, alarms, smoke investigations.
- Medical — aid responses, medic units, triage, overdose calls, cardiac events.
- Traffic — motor-vehicle accidents, freeway blocks, DUIs, collisions, traffic complaints.
- Police — general SPD calls that don't fall into a more specific bucket above (disturbances, theft reports, welfare checks, etc.).
- Hazmat — hazardous-materials response, natural-gas leaks.
- Rescue / Other — water rescues, technical rescues, calls that don't fit cleanly.
Categorization is rule-based and deterministic, not machine-learned. The exact rules are visible in the open-source lib/incidents.js file in our repository. If you disagree with a specific categorization choice, the rules are easy to inspect and easy to argue about — that's the point of keeping them simple.
On top of category, we tag a small number of incidents with a severity flag — "high" or "elevated" — based on type strings like "structure fire", "working fire", "shooting", or "stabbing". This is purely a display hint, not an authoritative severity rating. The Seattle Fire and Police Departments have their own internal priority systems and we do not have access to them.
How fresh is the data?
The fire feed typically lags real life by several minutes; the City refreshes it every five minutes. The police feed typically lags by several hours or more because SPD calls are released only after they are cleared and the dataset is updated once a day — that's a choice the City makes about its dataset, not something we can speed up. We re-query both feeds every minute and re-render the page on the client every thirty seconds, so the freshest version of upstream data is usually on screen within ninety seconds of the City publishing it.
If our backend cannot reach the upstream feeds — for example, during a Socrata outage — the status indicator in the header changes to "DEGRADED" or "OFFLINE" and the most recent successful pull stays on screen.
What we strip out
Both upstream datasets are pre-redacted by the City of Seattle. They do not contain caller names, victim names, suspect names, witness names, or first-responder names. They also do not contain badge numbers, dispatch transcripts, or audio, and the fire dataset does not list responding units. We do not display unit identifiers, and we make no attempt to obtain any of the withheld information.
Fire calls are shown at the dispatch-recorded address and the coordinates the City publishes for it. Police calls are located only approximately: to protect privacy, SPD generalizes call locations to the police beat, so a police pin marks the general area, not the exact spot.
Optional scanner audio
For users who want to listen to live dispatch traffic, the map panel can optionally embed an audio stream from OpenMHz, a community-run scanner-audio archive. OpenMHz is not affiliated with Seattle Breaking or with the City of Seattle. Audio is provided "as is" by the upstream community. Audio playback is opt-in and only loads when the operator has configured a specific system code.
Known limitations
Some limitations worth knowing before you draw any conclusions from the data:
- Misclassifications happen. Dispatchers categorize calls under time pressure based on what a caller reports, not on what is actually happening. A "shooting" call may turn out to be fireworks; a "structure fire" may turn out to be burnt toast. The upstream feed does not always backfill corrections.
- Cancellations are not always reflected. If a unit is dispatched and then cancelled en route, the event may remain in the feed with its original type.
- Geocoding errors. A small fraction of records have latitude/longitude values that fall outside Seattle or are clearly off. We filter the most obvious ones, but some slip through.
- Police data is delayed. SPD events do not appear in real time. Treat the Police filter as "recent activity," not "right now."
- Volume varies widely by time of day. Fire and EMS dispatches peak from late morning through late afternoon — about 6,000 a year in each hour from 11 a.m. to 6 p.m. — and bottom out around 4 a.m., at roughly 2,400.
Open source
The entire pipeline — data fetching, categorization rules, severity tagging, and rendering — is a few hundred lines of JavaScript. We are happy to share the source on request and intend to publish it under a permissive license once we've tidied a few rough edges. For now, write to editor@seattlebreaking.com if you'd like to inspect the code.
This is not a 911 substitute
It really isn't. The data is delayed. The categorizations are simplified. The site goes offline sometimes. If you have an active emergency, call 911. Seattle Breaking exists to provide context after the fact, not to support real-time decisions about personal safety.