NHTSA Recall, Complaint & Safety Spike Monitor avatar

NHTSA Recall, Complaint & Safety Spike Monitor

Pricing

from $2.00 / 1,000 intelligence events

Go to Apify Store
NHTSA Recall, Complaint & Safety Spike Monitor

NHTSA Recall, Complaint & Safety Spike Monitor

Monitor official NHTSA data for new recalls, complaints, and statistically defined complaint spikes by vehicle or component. Get severity scores, crash/fire/injury/death signals, before/after context, and auditable spike math. Stateful baselines prevent historical records from appearing as new.

Pricing

from $2.00 / 1,000 intelligence events

Rating

0.0

(0)

Developer

Johnn Mottin

Johnn Mottin

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

4 days ago

Last modified

Share

Monitor new NHTSA recalls, complaints, and statistically defined safety spikes

Monitor the vehicles you care about and receive structured events when the official NHTSA data changes.

This Actor does more than re-export recall and complaint history. It maintains per-vehicle state so historical recalls and complaints do not keep appearing as "new", and it evaluates complaint volume against each vehicle's own preceding baseline to detect unusual spikes.

Events can include crash, fire, injury, death, Park It, Park Outside, spike strength, and same-component recall signals. Severity is deterministic and every point is explained in severityEvidence.

No browser automation. No API key. No LLM in runtime.

Key features

  • New NHTSA recall monitoring
  • New owner complaint monitoring
  • Whole-vehicle complaint spike detection
  • Component-level spike detection
  • Make + model + model year monitoring
  • Persistent per-vehicle baseline
  • Historical recalls/complaints suppressed on first sight
  • Auditable spike arithmetic
  • Crash, fire, injury, and death signals
  • Park It and Park Outside recall warnings
  • Deterministic severity score
  • Severity evidence on every event
  • Same-component recall signal for component spikes
  • Configurable recent and baseline windows
  • Configurable absolute-volume floors
  • Optional monthly complaint distribution
  • Up to 50 vehicles per run
  • Free RUN_SUMMARY
  • Health checks and controlled source failures
  • Pay Per Event

Unofficial community Actor. Not affiliated with, sponsored by, or endorsed by the National Highway Traffic Safety Administration (NHTSA), the U.S. Department of Transportation, or any vehicle manufacturer. Data comes from the official public NHTSA API.


What this Actor is for

A normal NHTSA lookup answers:

What recalls and complaints exist for this vehicle?

This Actor is designed for recurring monitoring:

What is genuinely new, and is complaint activity behaving unusually?

Typical use cases include:

  • fleet safety monitoring;
  • dealership and used-vehicle risk workflows;
  • automotive research;
  • warranty and quality research;
  • insurance or claims research;
  • vehicle-owner safety alerts;
  • component-level complaint surveillance;
  • automotive data products;
  • scheduled safety dashboards;
  • webhook and automation pipelines.

Important: the first observation creates a novelty baseline

NEW_RECALL and NEW_COMPLAINT are stateful events.

The first successful observation of a vehicle records the current known recall campaign numbers and complaint ODI numbers.

It does not turn the existing history into new events.

Example:

First observation:
12 recalls already exist
420 complaints already exist
NEW_RECALL events: 0
NEW_COMPLAINT events: 0

If NHTSA later exposes one unseen recall and two unseen complaints:

Next observation:
NEW_RECALL: 1
NEW_COMPLAINT: 2

This prevents historical data from being repeatedly billed as novelty.


Important: spike events can appear on the first run

COMPLAINT_SPIKE and COMPONENT_SPIKE are different.

They do not depend on the persistent "seen ID" baseline.

They are calculated from dated complaint records returned in the current run:

recent window
versus
preceding baseline window

Therefore, a statistically qualifying spike can be emitted on the first observation of a vehicle.


Who it's for

Fleet and vehicle-safety teams

Monitor a list of make/model/year combinations and route meaningful safety events into internal workflows.

Dealerships and automotive marketplaces

Use recurring monitoring as one public-data signal in vehicle-risk research.

The Actor does not decide whether a vehicle should be bought, sold, repaired, or driven.

Automotive quality and research teams

Study:

  • new complaint arrival;
  • recall publication;
  • component concentration;
  • complaint-rate changes;
  • severity signals.

Data and automation teams

Connect structured events to:

  • Slack;
  • Microsoft Teams;
  • email workflows;
  • webhooks;
  • n8n;
  • Make;
  • databases;
  • dashboards;
  • ticketing systems;
  • internal applications;
  • AI analysis downstream.

How it works

For each vehicle, the Actor:

  1. validates and normalizes make, model, and model year;
  2. loads persistent state for that vehicle;
  3. requests recalls from NHTSA;
  4. requests owner complaints from NHTSA;
  5. normalizes endpoint-specific date formats and fields;
  6. identifies unseen recall campaign numbers;
  7. identifies unseen complaint ODI numbers;
  8. splits complaints into recent and baseline windows;
  9. calculates whole-vehicle spike math;
  10. groups complaints by component;
  11. calculates component-level spike math;
  12. assigns deterministic severity;
  13. writes admitted CHANGE_EVENT records;
  14. advances vehicle state only after successful source reads;
  15. writes a free RUN_SUMMARY;
  16. persists operational STATS.

A failure for one vehicle does not automatically destroy successful results from other vehicles.


Data source

The Actor uses the public NHTSA API:

https://api.nhtsa.gov

Endpoints used by this implementation:

/recalls/recallsByVehicle
/complaints/complaintsByVehicle

Queries use:

make
model
modelYear

No NHTSA API key is required for these public endpoints.


Input

{
"vehicles": [
{
"make": "Honda",
"model": "Civic",
"modelYear": 2022
},
{
"make": "Ford",
"model": "Explorer",
"modelYear": 2021
}
],
"eventTypes": [
"NEW_RECALL",
"NEW_COMPLAINT",
"COMPLAINT_SPIKE",
"COMPONENT_SPIKE"
],
"recentWindowDays": 30,
"baselineWindowDays": 365,
"spikeFactor": 2,
"minRecentComplaints": 5,
"minComponentComplaints": 3,
"minBaselineCount": 10,
"minComponentBaselineCount": 5,
"maxComplaintsPerVehicle": 500,
"maxResults": 1000,
"maxRuntimeMs": 300000,
"includeDistribution": false
}

Input fields

FieldDefaultDescription
vehiclesrequiredUp to 50 { make, model, modelYear } entries.
eventTypesall fourEvent types to emit.
recentWindowDays30Recent complaint window. Range: 1–180 days.
baselineWindowDays365Preceding baseline window. Range: 30–1,825 days.
spikeFactor2Minimum observed/expected factor for a spike after volume floors are met.
minRecentComplaints5Absolute recent-volume floor for vehicle spikes.
minComponentComplaints3Absolute recent-volume floor for component spikes.
minBaselineCount10Baseline-volume floor for vehicle spikes.
minComponentBaselineCount5Baseline-volume floor for component spikes.
maxComplaintsPerVehicle500Maximum complaint records used per vehicle. Range: 1–2,000.
maxResults1000Hard cap on billable events. Range: 1–10,000.
maxRuntimeMs300000Runtime cap in milliseconds.
includeDistributionfalseAdd monthly complaint distribution to the free summary.
debugfalseAdditional diagnostic logs.

Vehicle format

Each vehicle uses:

{
"make": "Honda",
"model": "Civic",
"modelYear": 2022
}

The Actor creates a normalized identity such as:

HONDA/CIVIC/2022

Duplicate normalized vehicles are removed.

The supported model-year validation range is:

1949–2100

A make/model/year that NHTSA does not recognize can fail only that vehicle while the rest of the batch continues.

Vehicle name spelling — measured examples

NHTSA's API only accepts its exact model names. A close-but-wrong spelling is rejected by the source (HTTP 400) and that vehicle yields nothing — no baseline, no events, and no charge for it. Measured directly against the source (August 2026):

spelling that worksspelling that returns nothing
ford / f-150 / 2024 — 10 recallsford / f150 / 2024 — rejected by the source
chevrolet / silverado 1500 / 2024 — 2 recallschevrolet / silverado / 2024 — rejected by the source
honda / civic / 2024 — 3 recallshonda / civic sedan / 2024 — rejected by the source
toyota / corolla / 2024 — 2 recalls
jeep / wrangler / 2024 — 11 recallstesla / model 3 / 2024 — intermittent source error (500)

Tip: if a vehicle unexpectedly returns nothing, check the canonical model name on nhtsa.gov (its search shows the exact form, e.g. "F-150", "Silverado 1500") and retry with that spelling. Recall counts above are the measured sample at probe time, not a promise of future coverage.


Event types

The Actor supports four intelligence events.

NEW_RECALL

A recall campaign number that was not present in the vehicle's previously seen state.

NEW_COMPLAINT

A complaint ODI number that was not previously seen for the vehicle.

COMPLAINT_SPIKE

Recent whole-vehicle complaint volume exceeds the expected count derived from the preceding baseline and passes the absolute-volume floors.

COMPONENT_SPIKE

The same statistical test, but for one complaint component such as:

STEERING
SERVICE BRAKES
ELECTRICAL SYSTEM
AIR BAGS

How spike detection works

For a selected vehicle:

recent
=
complaints filed during recentWindowDays
baseline
=
complaints filed during baselineWindowDays immediately before the recent window

The expected complaint count in the recent window is:

baselineDailyRate
=
baselineCount / baselineWindowDays
expectedInRecent
=
baselineDailyRate × recentWindowDays

The observed factor is:

observedFactor
=
recentCount / expectedInRecent

A vehicle-level spike requires all of these:

baselineCount >= minBaselineCount
recentCount >= minRecentComplaints
recentCount >= expectedInRecent × spikeFactor

A component spike uses the same formula with:

minComponentBaselineCount
minComponentComplaints

Why absolute-volume floors matter

Without floors, a tiny baseline can generate a visually dramatic but weak ratio.

Example:

expected recent count = 0.2
observed recent count = 1
observed factor = 5×

One complaint should not automatically become a high-confidence spike simply because the denominator is tiny.

The absolute floors are part of the decision contract.


Spike evidence is included in the event

A spike event carries the numbers needed to reproduce the decision.

The baseline/before context can include:

windowDays
from
to
count
dailyRate
expectedInRecentWindow

The current context can include:

windowDays
from
to
count
observedFactor
crashes
fires
injuries
deaths
component

The event also includes:

thresholdsApplied

so downstream users can see exactly which floors and factor were active.


Severity intelligence

Severity is deterministic and versioned.

Current rule version:

nhtsa-severity-2026-08

The score can use signals such as:

SignalPoints
NHTSA Park It warning+40
NHTSA Park Outside warning+30
Deaths in the relevant complaint window+30
Injuries in the relevant complaint window+20
Crash or fire in the relevant complaint window+15
Complaint factor ≥ 3×+15
Recall on the same spiking component+20

Severity levels:

critical >= 80
high >= 60
medium >= 35
low >= 0

Every contribution is listed in:

severityEvidence

This is an explainable risk-prioritization signal, not a prediction of future harm.


Recall fields

A NEW_RECALL event can expose NHTSA fields such as:

campaignNumber
actionNumber
component
summary
consequence
remedy
manufacturer
reportReceivedDateRaw
reportReceivedDate
parkIt
parkOutside
overTheAirUpdate

Missing values return null.


Complaint fields

A NEW_COMPLAINT event can expose fields such as:

odiNumber
manufacturer
crash
fire
numberOfInjuries
numberOfDeaths
dateComplaintFiledRaw
dateComplaintFiled
dateOfIncidentRaw
dateOfIncident
summary
components
componentsList

Complaint text is user-submitted public NHTSA data.

The Actor does not independently verify the complaint narrative.


Output

The default dataset contains:

CHANGE_EVENT
RUN_SUMMARY

CHANGE_EVENT is the billable intelligence row.

RUN_SUMMARY is free.


Example — component complaint spike

{
"recordType": "CHANGE_EVENT",
"eventType": "COMPONENT_SPIKE",
"changeKind": "CHANGED",
"entityId": "nhtsa:vehicle/HONDA/CIVIC/2022/component/STEERING",
"vehicleEntityId": "nhtsa:vehicle/HONDA/CIVIC/2022",
"source": "api.nhtsa.gov",
"observedAt": "2026-08-16T14:22:41.183Z",
"changedFields": [
"complaintRate"
],
"previous": {
"windowDays": 365,
"from": "2025-08-17",
"to": "2026-07-17",
"count": 12,
"dailyRate": 0.032877,
"expectedInRecentWindow": 0.9863
},
"current": {
"make": "HONDA",
"model": "CIVIC",
"modelYear": 2022,
"component": "STEERING",
"windowDays": 30,
"from": "2026-07-18",
"to": "2026-08-16",
"count": 9,
"observedFactor": 9.125,
"crashes": 1,
"fires": 0,
"injuries": 2,
"deaths": 1
},
"thresholdsApplied": {
"spikeFactor": 2,
"minRecentAbsolute": 3,
"minBaselineCount": 5
},
"recallOnSameComponent": false,
"severityScore": 80,
"severityLevel": "critical",
"severityEvidence": [
"1 death(s) reported in the window: +30",
"2 injury/injuries reported in the window: +20",
"1 crash(es) and 0 fire(s) reported: +15",
"Complaint rate 9.125x above the baseline: +15"
],
"severityVersion": "nhtsa-severity-2026-08"
}

Core event fields

FieldDescription
recordTypeCHANGE_EVENT.
eventTypeOne of the four domain event types.
changeKindADDED or CHANGED.
entityIdStable canonical event/entity identity.
vehicleEntityIdStable make/model/year identity.
sourceapi.nhtsa.gov.
observedAtObservation timestamp.
previousObservedAtPrevious vehicle observation timestamp when available.
changedFieldsFields considered changed by the canonical event.
previousBaseline/before context.
currentCurrent recall, complaint, or spike context.
severityScoreDeterministic numeric score.
severityLevellow, medium, high, or critical.
severityEvidenceExplanation for every score contribution.
severityVersionVersion of the rules.

Spike events can additionally include:

thresholdsApplied
recallOnSameComponent

RUN_SUMMARY

Every run attempts to write one free final summary.

It can include:

recordsWritten
unitsRequested
unitsOk
unitsFailed
capReason
qualityAlert
sourceUnavailable
warnings
units
outcomeKind
eventsByType
baselinesCreated
recallsFetched
complaintsFetched
thresholds
monthlyDistribution
cost
pricingLabel

This means a quiet monitoring run can still return visible operational information even when there are no billable events.


Monthly distribution

With:

{
"includeDistribution": true
}

the free summary includes complaint counts grouped by:

vehicle
month

This is intended for threshold calibration and diagnostic analysis.

It does not create additional billable intelligence events.


STATS

Operational statistics are persisted in the default Key-Value Store as:

STATS

Depending on the run, STATS can contain:

  • HTTP requests;
  • retries;
  • recalls fetched;
  • complaints fetched;
  • charged results;
  • charge errors;
  • quality alerts;
  • health signals;
  • warnings;
  • source availability;
  • runtime;
  • compute units;
  • cost metrics;
  • cap reason.

Scheduling

This Actor is designed for recurring checks.

A practical starting cadence for many workflows is:

daily

The first successful observation of each vehicle establishes novelty state.

Later scheduled runs can emit only unseen recalls and complaints.

Spike detection is recalculated from the complaint history available in each run.


  1. Add the vehicles you need to monitor.
  2. Run once to establish novelty state.
  3. Save the input as an Apify Task.
  4. Open Schedules.
  5. Choose the cadence.
  6. Send future CHANGE_EVENT records downstream.

Possible destinations include:

  • Slack;
  • Teams;
  • email workflows;
  • n8n;
  • Make;
  • webhooks;
  • databases;
  • dashboards;
  • ticketing systems.

Example fleet-monitoring input

{
"vehicles": [
{
"make": "Ford",
"model": "Explorer",
"modelYear": 2021
},
{
"make": "Toyota",
"model": "RAV4",
"modelYear": 2023
},
{
"make": "Honda",
"model": "Civic",
"modelYear": 2022
}
],
"eventTypes": [
"NEW_RECALL",
"COMPLAINT_SPIKE",
"COMPONENT_SPIKE"
],
"recentWindowDays": 30,
"baselineWindowDays": 365,
"spikeFactor": 2,
"maxResults": 500
}

A downstream workflow can then:

  • create a safety review ticket for a new recall;
  • prioritize a critical spike;
  • notify a fleet manager;
  • store events in a risk database;
  • route events to an analyst;
  • generate a human-readable report.

API

Run the Actor through the Apify API:

curl -s "https://api.apify.com/v2/acts/<YOUR_USERNAME>~nhtsa-safety-intelligence/run-sync-get-dataset-items?token=<YOUR_APIFY_TOKEN>" \
-X POST \
-H "Content-Type: application/json" \
-d '{
"vehicles":[
{"make":"Honda","model":"Civic","modelYear":2022}
],
"eventTypes":["NEW_RECALL","NEW_COMPLAINT","COMPLAINT_SPIKE","COMPONENT_SPIKE"],
"maxResults":100
}'

Replace:

<YOUR_USERNAME>
<YOUR_APIFY_TOKEN>

with your Apify account values.


Integrations

Use with:

  • Apify API;
  • Tasks;
  • Schedules;
  • webhooks;
  • n8n;
  • Make;
  • Slack;
  • Teams;
  • databases;
  • dashboards;
  • custom applications;
  • AI agents downstream.

Pricing

This Actor uses Pay Per Event.

The code uses two custom billing events:

actor-start
intelligence-event

actor-start

Called once after valid input has been accepted.

Invalid input is rejected before the billing gate opens.

intelligence-event

Charged per delivered CHANGE_EVENT.

A batch can contain:

NEW_RECALL
NEW_COMPLAINT
COMPLAINT_SPIKE
COMPONENT_SPIKE

The free RUN_SUMMARY never goes through event billing.

The Pricing tab on the Actor page is always the authoritative source for current prices.


What is free

The following do not create an intelligence-event charge:

  • historical recall/complaint IDs learned during the first observation;
  • previously seen recalls;
  • previously seen complaints;
  • non-qualifying complaint-rate changes;
  • RUN_SUMMARY;
  • monthly distribution inside the summary;
  • health diagnostics;
  • invalid input rejected before charging.

A qualifying spike can still be billable on the first vehicle observation because spike detection does not depend on novelty state.


Cost control

Primary user controls:

vehicles
eventTypes
maxResults
maxRuntimeMs
maxComplaintsPerVehicle

Spike thresholds also control signal volume:

recentWindowDays
baselineWindowDays
spikeFactor
minRecentComplaints
minComponentComplaints
minBaselineCount
minComponentBaselineCount

Lower thresholds can increase event volume and noise.

Higher thresholds reduce sensitivity.


Run health

The Actor includes explicit health and contract checks.

It validates important NHTSA response shapes instead of silently accepting unexpected data.

It also monitors historical source-volume signals after enough persisted runs exist.

Operational outcomes can distinguish:

  • one vehicle failing;
  • all vehicles failing;
  • source outage;
  • timeout;
  • input error;
  • API contract change;
  • result cap;
  • runtime cap;
  • billing limit.

Honest limits

This is not a recall predictor

The Actor monitors recalls already published by NHTSA.

It does not predict that NHTSA will issue a future recall.

Complaint spikes are signals, not proof of a defect

A spike means complaint activity exceeded the configured statistical threshold.

It does not by itself prove:

  • a manufacturing defect;
  • causation;
  • legal liability;
  • recall eligibility.

Complaint narratives are user-submitted

Owner complaints are public reports submitted to NHTSA.

The Actor does not independently verify the factual accuracy of each narrative.

Spike quality depends on history

A vehicle/component with insufficient baseline volume does not emit a spike.

That is intentional.

maxComplaintsPerVehicle can limit the analytical history

If the NHTSA response contains more complaint records than your configured cap, only the admitted subset is used by the current run.

For highly complained-about models, use a sufficiently large cap.

State is keyed by make/model/year

Novelty monitoring is based on the normalized vehicle combination:

MAKE/MODEL/MODEL_YEAR

It is not VIN-specific.

The current product does not include crash-test ratings

This implementation focuses on:

  • recalls;
  • owner complaints;
  • complaint spikes;
  • component spikes.

The current product does not monitor service bulletins or investigations

Those sources are outside the current v1 contract.

NHTSA source behavior can change

The Actor includes response-contract validation, retries, and controlled errors, but final data availability depends on the public NHTSA API.

No AI in runtime

Spike decisions and severity scores use declared deterministic rules.

No generative model invents safety conclusions.


FAQ

Do I need an NHTSA account?

No.

Do I need an NHTSA API key?

No for the public endpoints used by this Actor.

Does it use browser automation?

No.

Can I monitor multiple vehicles?

Yes.

Up to 50 input entries per run.

Why did the first run not emit old recalls?

Because the first successful observation creates the novelty baseline.

Existing recall campaigns are remembered rather than presented as new.

Why did the first run still emit a spike?

Spike detection uses the complaint dates available in that run.

It does not require prior Actor state.

What makes a complaint spike?

The recent complaint count must:

  1. have enough baseline volume;
  2. pass the recent absolute-volume floor;
  3. be at least spikeFactor times the expected recent count derived from the baseline rate.

Can spikeFactor be decimal?

Yes.

For example:

{
"spikeFactor": 2.5
}

Can I monitor only new recalls?

Yes.

{
"eventTypes": [
"NEW_RECALL"
]
}

Can I disable individual complaint events but keep spikes?

Yes.

{
"eventTypes": [
"COMPLAINT_SPIKE",
"COMPONENT_SPIKE"
]
}

What is severityEvidence?

A list explaining exactly which deterministic rules contributed points to the severity score.

Is critical an official NHTSA classification?

No.

It is this Actor's deterministic prioritization level, identified by severityVersion.

What does recallOnSameComponent mean?

For a component spike, the Actor checks whether a current recall component appears to correspond to the spiking complaint component.

It is a matching signal, not proof that the complaints and recall share the same cause.

Are quiet runs charged per result?

No intelligence-event is created when there are no qualifying events.

The configured start event can still apply.

Is the summary charged?

No.

Can I schedule it?

Yes.

Is this affiliated with NHTSA?

No.

This is an independent community Actor using public NHTSA data.


Support

For bugs, questions, or requested fields:

johnatan291303@gmail.com

You can also use the Issues tab on the Actor page.


Part of the JM Forge suite

Also from the same developer:

  • NHTSA Vehicle Recalls & Complaints — US Vehicle Safety — batch lookup of public NHTSA recall and complaint records.
  • GitHub Release Monitor & Dependency Alerts — stateful monitoring of genuinely new GitHub releases.
  • Shopify Competitor Sale & New Arrival Insights — public Shopify promotion and assortment intelligence.

JM Forge Actors remain independent tools.

Use the lookup Actor when you need the current NHTSA records.

Use this Actor when you need recurring safety events and complaint-spike intelligence.