Is This Battery Pack DOA, a Warranty Failure, or Just Worn Out?

Sort the failure before you report it. A pack that comes back dead is one of three things, dead on arrival, a warranty defect, or normal wear, and the category is settled by four pieces of evidence rather than by how the machine behaves when a technician plugs it in: time in service measured from first power-up, cycle count and depth-of-discharge history pulled from the BMS log, a capacity test run at the conditions the guarantee actually names, and the ambient and duty record for that specific install. Choose the wrong category and a genuine defect gets processed as end-of-life, or a worn-out pack gets filed as a defect and burns credibility you will want later.

The pack on my bench arrived with a return note that said "won't hold charge." That note is worth almost nothing. What is worth something is the CSV I pulled off the BMS before anyone cleared the fault codes, the serial on the label that matches the shipping record, and the commissioning date in the install log. Three artifacts, ten minutes, and the argument is half decided before I pick up the phone.

I run the same four questions every time, in the same order, because the order is what keeps me honest. If I start with the capacity test, I find what I expect to find. If I start with the cycle counter, I get a number that flatters or damns the pack depending on how the machine happened to be cycled. So: when did it first power up, how many cycles and at what depth, what does it test at under the named conditions, and what does the event log say about how it was treated.

The DOA clock starts sooner than the calendar

A custom pack's DOA window is usually written against receipt or first power-up, not against a month count. That distinction matters more than it looks. A pack that sits on a shelf for four months waiting for the robot build is aging without working, and a receipt-based window can run out before the machine ever runs a shift. Ask which clock the term uses during the RFQ, in writing, and make the supplier state it in plain words rather than leaving it inside a definitions section.

Then start the clock you want started. When the pack is commissioned, get a timestamped commissioning record: date, time, serial, ambient temperature, state of charge out of the crate, first charge current, and who signed it. That single page is the cheapest insurance in the whole program, because it settles the DOA question before it becomes a dispute about who remembers what.

Cycle count tells you which family the failure belongs to

Pull cycle count and cumulative ampere-hour throughput first, then the rest.

If a pack fails at a couple hundred equivalent full cycles against a guarantee written at two thousand, that is not wear. Something is wrong that has nothing to do with time in service, and the conversation is about a defect. If it fails at 1,850 cycles reading 79 percent of rated on a correct test, you have a question about the guarantee curve, not about a defect. Those are two different emails, two different people at the supplier, and two different outcomes on freight.

What the depth-of-discharge histogram is actually for

Most BMS platforms keep a histogram of how the pack has been cycled, and most buyers never export it. That is a mistake, because the histogram is the difference between "this pack faded early" and "this pack faded on schedule for how you used it."

A pack run down to 90 percent depth every cycle, against a guarantee that assumed 80 percent, will fade faster and the histogram proves it. That cuts against you. But the same export can also be your evidence that the duty cycle stayed inside the assumption the guarantee was priced on, and in that case it is the strongest page in the file. Either way, you cannot argue about it if you did not capture it.

A capacity number is meaningless without the condition attached

Capacity fade guarantees are written as a percentage of rated capacity at a defined cycle count and a defined test condition: discharge rate, temperature, cutoff voltage. If the term says 80 percent at 2,000 cycles at 0.5C and 25 °C, then a bench test at 0.2C in a 15 °C shop reads high, and a test at 1C in a 35 °C bay reads low. Run the test at the named condition, or you will spend the whole claim arguing about your test instead of the pack.

One more trap: find out whether "rated capacity" means nameplate or beginning-of-life measured. They are not always the same number, and a spec that stays silent on which one it means is a spec that gets argued about at the worst possible moment, usually with a pallet of dead packs behind you.

The pack that passes on the bench and still goes back

Communication failures. CAN dropouts under vibration, a BMS that goes silent after a hard bump, isolation faults that only show up when the chassis is wet, a contactor that welds intermittently. A static capacity test finds none of these. I have watched a pack pull 100 percent of rated on the bench and still be a legitimate return, because the failure is intermittent and the proof lives in the event log rather than in the discharge curve.

When that is the shape of the failure, stop chasing the capacity number and build a timeline instead: fault code, timestamp, machine state, ambient, what the operator was doing, how long it lasted, whether a power cycle cleared it. Ten timestamped occurrences is a case. One occurrence and a description from a technician is a conversation.

Whatever you do, pull the logs before you ship the pack back. Once it is in the supplier's lab, you are reading their report about your evidence, and some returns come back wiped or refurbished before anyone thinks to ask you for the export.

The three exclusions that end most claims

Over-discharge, over-temperature, and unauthorized BMS changes. Those three clauses are in nearly every custom pack warranty, and they are where most claims actually die, not at the capacity number.

Over-discharge usually leaves fingerprints: a pack parked at low state of charge for months, a robot left powered over a long weekend until the BMS cut out and the parasitic load kept pulling, a cell group dragged under cutoff. Over-temperature shows up as a charging event in a hot aisle, a blocked fan, or a cooling duct packed with dust. Unauthorized changes are the quietest killer: a reflashed firmware, an edited protection threshold, a swapped board.

So keep a change log with dates. If your controls engineer tunes a CAN parameter or a technician swaps a BMS board, that goes in the file the same day. If the supplier finds a modified parameter during failure analysis, the claim is finished regardless of what actually killed the pack, and you will not get that argument back.

Making wear look like wear

If it is wear, say so, and do not file. A warranty claim on a pack that is simply at the end of its rated life gets flagged, and it makes the next claim harder at exactly the moment you need the supplier to take you seriously.

What you do instead is document the fade curve so the replacement becomes a budget line rather than a surprise: capacity at commissioning, then at 500, 1,000, and 1,500 cycles, all at the named conditions, plus the fleet's duty cycle and ambient range. That record answers a different question from "is it broken." It answers "is the guarantee being met," and if it is not, you have a defect case with a head start.

When it is a defect, present it as a deviation rather than a verdict. Not "the pack is bad," but: serial, commissioning date, cycle count, depth-of-discharge distribution, ambient range, capacity at the named test condition, date of first fault, fault codes, and the gap from the guaranteed curve. One page, in order, with the raw exports attached behind it.

Where the categories blur

A pack over-discharged once in month two and failing in month twenty is a wear case with a footnote. A pack that fails at 300 cycles after six months in a bay running 45 °C ambient might be a defect and might be an application problem, and the honest answer is that you need the temperature history to know which.

Pick the category the evidence supports, disclose the footnote in the first paragraph of the claim, and let the supplier argue with the data instead of with your characterization. The category is not a moral judgment about the pack. It is a routing decision, and it determines who pays freight both ways, who runs the failure analysis, and whether the replacement lands on a warranty line or a capital line.

The pack does not care what you call it. Your supplier does. Call it the thing the log says.