DFR in the sidebar is where a Drone-as-First-Responder program keeps its incident record: one row per call the drone answered, with the call type, the outcome, and a response time computed the same way every time. It sits apart from the flight log on purpose — a flight record says what the aircraft did, an incident record says what the call was and how the program performed on it.
Any signed-in user can read the page, and unless you are a global admin you see only your own unit's incidents. Logging or editing an incident requires Supervisor or above.
Before you start. DFR is an Enterprise capability: it runs on a dedicated instance with the
dfrfeature enabled and is not available on the shared plans. If DFR is missing from the Flights group in the sidebar, the feature is off for your instance.
What a DFR incident record holds
An incident is a small, deliberate record. Only the date and the call type are required; the rest exists so the numbers you report later hold up.
| Field | What it holds |
|---|---|
| Date | The date of the call — the axis every monthly chart is built on |
| Unit | The unit that answered, chosen from your configured units |
| Call Type | Free text, so it can match your CAD vocabulary (for example 459 Burglary) |
| Priority | Free text, for your dispatch priority scheme (for example Priority 1) |
| Response time inputs | A typed duration, or call-received / launched / on-scene timestamps, depending on the configured method |
| Scene coordinates | lat and lng of the incident, which is what makes telemetry measurement possible |
| Linked flight | The ID of the flight that answered the call |
| Outcome | Arrest, Assisted Units, Call Cleared, Cancelled En Route, Unfounded, or Other |
| Notes | Free text |
Two more values are stored but not typed by you: responseSeconds, the effective response time, and responseSource, which records whether that number came from telemetry, timestamps, or manual entry. Both are written on every save. Creating, editing, and removing an incident are recorded in the audit trail as dfr_incident events.
Logging an incident
- Open DFR and click Log Incident (supervisors and above).
- Set the Date, pick the Unit, and type the Call Type and Priority.
- Fill in the response fields the dialog shows — they change with your configured methodology.
- Choose an Outcome and add Notes if the call needs explaining.
- Click Log Incident.
The dialog's subtitle names the methodology in force before you fill anything in, and the fields follow it. Manual mode gives you a single Response Time field split into minutes and seconds. Timestamps mode gives you three date-and-time pickers — Call received, Launched, On scene. Automatic mode gives you those three plus Linked flight ID, Scene latitude, and Scene longitude.
Saved incidents land in the Incidents table at the bottom of the page: Date, Unit, Call Type, Priority, Response, and Outcome, 15 rows to a page, searchable across call type, unit, outcome, and priority. The pencil icon reopens the same dialog for editing. Three stat cards sit above the charts: DFR Incidents, Avg Response (the mean across incidents that have a response time), and Under 2 Minutes (the share of those at 120 seconds or less).
The three response-time methodologies
Response time is the number a DFR program lives and dies by, and also the easiest number to compute three ways and get three answers. So the methodology is an agency-wide setting, not a per-incident choice: a System Admin picks one on Admin, in the DFR Response Time card.
| Method | What it measures | What it needs | Use it when |
|---|---|---|---|
| Manual | A duration someone types in | Nothing beyond the typed value | You are starting out, or the timing lives in a CAD system you read off by hand |
| Timestamps | On-scene minus call-received | Both times logged per incident | Crews record dispatch and arrival times reliably and you want an arithmetic, auditable number |
| Automatic | First telemetry point within 150 m of the scene | A linked flight with telemetry, plus scene coordinates | Your DFR flights carry telemetry and you want arrival measured, not reported |
Manual is self-reported and should be treated that way in any public number. Timestamps is auditable but only as good as the discipline behind the two times. Automatic is the only one where arrival is measured by the aircraft itself, and it degrades gracefully when an input is missing.
Manual
The typed minutes and seconds are the answer; nothing is derived, and responseSource is recorded as manual. If nothing is typed, the incident has no response time and drops out of the averages and the distribution chart.
Timestamps
Response time is on-scene minus call-received. If no call-received time was logged, the launched time stands in as the start, which turns the figure into flight time to scene rather than call-to-scene — worth knowing before comparing the two. The result only counts when on-scene is actually after the start; otherwise the incident falls back to whatever typed duration the record carries.
Automatic (telemetry-measured)
Automatic measures first. With a linked flight and scene coordinates, the system pulls that flight's telemetry samples, discards clock-glitch readings more than 12 hours off the flight's median timestamp, and takes the first remaining sample within 150 metres of the scene as on-scene. The clock starts at the logged call-received time when there is one, and at the flight's first valid sample when there is not.
The measurement is skipped — not guessed — when the flight is not linked, the scene has no coordinates, fewer than two usable samples survive filtering, or the aircraft never came within 150 m. Each of those falls back to the timestamp calculation, then to a typed value. That is why responseSource matters: it tells you which of the three actually produced the number on a given row.
Telemetry has to exist for the flight. Automatic mode reads stored telemetry samples, which come from imported standard-format logs and from dock and live sources. A flight with no sample track cannot be measured, however precisely you enter the scene coordinates.
Changing the methodology later
Each incident's response time is recomputed from scratch every time that incident is saved — on creation and on every edit. Changing the agency setting does not sweep back through incidents already logged; there is no bulk backfill, so the page will mix old numbers computed the old way with new ones computed the new way.
To bring an older incident over, open it, fill in whatever the new method needs (timestamps, or a flight ID and scene coordinates), and save. That single save re-derives responseSeconds and stamps the new responseSource.
Switch before you publish, not after. Response averages feed the public transparency portal and the AB 481 report. Change the methodology, reconcile the incidents you care about, and only then quote a number externally.
Linking incidents to flights and pilots
The link from an incident to the rest of the program runs through the flight. Put a flight's ID in Linked flight ID — the last segment of that flight's detail-page URL, /flights/<id> — and the incident is tied to that record, and through it to the rPIC, the aircraft, and the participants on the flight. The field appears in the dialog in automatic mode, where it also drives the telemetry measurement; see working with flight records for finding the flight you want.
Flights are classified as DFR work separately, by the post-flight checklist: on a DFR-enabled instance, completing one requires declaring whether the flight was a Field Deployment or DFR. That answer, not the incident record, drives the field/DFR split on the Flights page and unit pages, and the flight scoping on the public portal.
Configuring the DFR charts
The chart strip between the stat cards and the incident table is configurable, and every metric in it comes from data you already collect.
A System Admin edits it on Admin in the DFR Charts card. Drag rows by the grip handle to reorder, set each chart to Half width or Full width in the two-column grid, click the color swatch to recolor a series (↺ restores the theme color), the × to remove one, and ＋ Add a chart… to add from the catalog. Save layout applies it. A layout holds up to 24 charts; with none selected, the page falls back to its defaults.
The built-in catalog draws entirely from incident records:
- Incidents per month and Avg response time — monthly lines
- Response time distribution — a bar chart bucketed into under 1 minute, 1–2, 2–5, and 5+ minutes
- By call type, By outcome, and By priority — breakdown pies
- Incidents by unit — a bar chart of which units the calls land on
Out of the box the page shows Incidents per month, Avg response time, By call type, and By outcome, each at half width — and the editor starts from exactly that set, so what you see in the admin card is what the page renders.
The picker also offers checklist-derived charts automatically. Every number, select, toggle, and checkbox item across your checklist templates becomes a chartable metric over the last 365 days of completed responses: number items as a monthly average line, select items as an answer-breakdown pie, toggles and checkboxes as a Yes/No pie. Add a question to a template and it appears in the catalog with no further setup. A chart with nothing behind it yet reads "No data collected yet."
Frequently asked questions
Why does my response time not match what I typed?
Because the typed value is only authoritative in manual mode. In timestamps and automatic mode the system derives the number and treats a typed duration as a last resort, used only when no timestamps and no telemetry measurement are available. Check the stored response source for the incident to see which method actually produced the figure, and confirm which methodology your agency has set on the Admin page.
Do I have to re-enter old incidents after changing the methodology?
No, but they will keep their old numbers until you save them again. Every incident recomputes on save, so opening one and clicking Save re-derives it under the current method — provided the inputs that method needs are present. There is no bulk recompute, so plan on reconciling the incidents that matter to your reporting rather than the whole history.
What counts as "on scene" in automatic mode?
The first telemetry point from the linked flight that falls within 150 metres of the incident's scene coordinates. The clock starts at the call-received time if one was logged, otherwise at the flight's first valid telemetry sample. If the aircraft never gets within that radius, or the flight has no usable telemetry, the incident falls back to its timestamps and then to a typed duration.
Can pilots log DFR incidents?
No. Pilots can open the DFR page and read the incidents in their scope, but the Log Incident button and the row edit action require Supervisor or above. Deleting an incident requires a unit admin. Everything a supervisor or admin does to an incident is recorded in the audit trail, so the edit history stays reviewable.
Why is a chart I added showing no data?
Because nothing has been collected for it yet in the range it covers. Checklist-derived charts look at the last 365 days of completed checklist responses, so a question added to a template last week will stay empty until crews answer it. Incident charts show only incidents already logged, and response charts only count incidents that ended up with a response time.
Where to go next
Incidents feed two things beyond this page. The AB 481 deployment report combines flights and incidents into one CSV or PDF, with a DFR block carrying incident count, average response, and breakdowns by call type and outcome — see reports and exports. With stats enabled, the public transparency portal publishes total incidents, arrests, assists, average response, and the top ten call types.
For the program-design side — staffing the launch site, writing the call-type matrix, deciding what to publish — read the DFR program guide, and the Part 91 COA and waiver guide for the authority most DFR operations fly under.