Methodology
This page says where each number comes from, what we do to it, and what it cannot tell you. It also says how the site itself is built, because some of the things we used to promise are easier to show than to say.
Known Issues clusters
Source. Complaints filed with NHTSA's Office of Defects Investigation (ODI). Anyone can file one. NHTSA publishes them with the vehicle's year, make and model, a component category, a date, and the driver's own description.
What we do. For each year/make/model with enough complaints on file, we group the complaints by what failed. Each group gets a short label, the NHTSA component code of a typical complaint, the number of complaints in the group, the date range, and two or three quoted complaints as examples. The grouping is done by a language model working from a fixed set of rules; the rules and the output are ours, the words in the quotes are the drivers'.
What keeps it honest. Every quote is checked byte-for-byte against the NHTSA complaint it cites. A quote that does not match the record exactly is dropped before publishing, and a vehicle that ends up with fewer than two grounded groups is held back instead of published. Labels may not use words like "common", "serious", "unreliable" or "dangerous", and may not invent statistics. Where NHTSA has its own wording for a failure, we use it.
What it cannot tell you. Complaint counts are raw. More popular vehicles collect more complaints because more of them exist. We do not have a count of how many of each vehicle are on the road, so we do not compute rates, and we do not rank vehicles by complaints. A cluster means "drivers reported this", not "this will happen to you". Long histories are clustered from a sample of the most recent complaints, and the date range field says so when that is the case.
Full schema and downloads: /data/known-issues.
NHTSA complaints
The same ODI records, summarized: complaint counts by vehicle and by component category, plus flags NHTSA attaches (crash, fire). We refresh these from NHTSA's public API. Counts on a vehicle page are the total on file for that year/make/model at the last refresh. We do not display complaint-reported deaths or injuries anywhere; that decision and the reason are in the FARS section below.
Recalls
NHTSA recall campaigns matched to year/make/model. A recall on a vehicle page is a campaign NHTSA lists for that vehicle; whether a specific car was fixed depends on its VIN, which we never ask for. Check your VIN on NHTSA's site for that.
Investigations
NHTSA defect investigations (preliminary evaluations, engineering analyses, recall queries) matched to the vehicles they name. An open investigation is a question NHTSA is asking, not a finding.
FARS deaths
The Fatality Analysis Reporting System is the federal census of every US traffic death. Where we show deaths, the number is occupant deaths in fatal crashes for that year/make/model over the stated crash years. FARS counts every occupant death whatever the cause; it does not mean the vehicle was at fault or defective, and counts are not adjusted for how many of each vehicle are on the road. Pedestrian deaths are not attributed to vehicles. The full method, including how vehicles are matched to FARS codes and where a within-segment comparison is allowed, is in the Death Report.
Maintenance intervals
The service intervals on vehicle pages are the manufacturer's published maintenance schedule, normalized into our own fields: service name, interval in miles, interval in months, and whether the item is inspect-or-replace. We do not reproduce the manual's text. Price ranges shown next to a service are our estimates from national average labor rates and parts costs, and are hidden where the spread is too wide to be useful.
Coverage and freshness
The hub shows, for every model year, how many vehicles we list and what share of them have a schedule, recalls, and Known Issues. The same table drives our internal dashboard, so the public number and the number we manage by are the same number. Each dataset page shows a "data through" date: the last time its source files were rebuilt. Downloads are regenerated on every site build.
How this site is built
These used to be listed as promises. They are still true; they are just easier to check than to believe.
- Looking up a vehicle needs no account, name or email. When you add your ZIP and mileage on a vehicle page, your browser keeps them in session storage for that visit; closing the tab clears them, and there is no cookie that remembers your area between visits. Each lookup is logged to our private analytics as year, make, model, mileage, ZIP and the metro that ZIP maps to, with no name attached. Those logs stay in Wrench.Pro tools and a private spreadsheet.
- Vehicle pages are built ahead of time from the data files described here. They do not call an outside service when you load them, and they do not read the database that the shop portal uses.
- Shops pay to be seen, not to change what you see. A paid placement is a labeled card. It cannot change a maintenance schedule, the order of recommendations, or whether a service is flagged as due. There is at most one labeled sponsored card on a page.
- What shops can learn from us is aggregate only. "Drivers in this area looked up brake service this month" is the level of detail that exists. There is no individual record to share.
- Recommendations come from the manufacturer's schedule. We also say when something is not due yet.
- Messages get read. Use the contact page for a bad recommendation, a shop that should not be listed, or a number that looks wrong.
Corrections
When a dataset changes in a way that affects what was published (a backfill, a schema change, a correction), we note it in the data changelog. If you find an error, tell us through the contact page and cite the row. Corrections are made in the source files, so the next build fixes every page and every download at once.
hub · known-issues · methodology · license · research (interpretation)