Hardware Acceptance Testing: What to Check Before Production
New hardware is at its most likely to fail in its first weeks, and that is the window when returning it is easy. This covers what to check before equipment goes into production.
Why acceptance testing pays
Two reasons.
Early-life failures are real. Component failures cluster at the start of life, and running equipment hard for a period before trusting it moves those failures into a window where they are an inconvenience rather than an incident.
The return window is short. Discovering a problem after it closes turns a supplier’s problem into yours. Our packing guide covers why transit damage in particular shows up late.
On arrival, before anything else
Three steps that take minutes and protect a claim.
Photograph the packaging before opening, particularly any damage.
Note damage on the delivery paperwork before signing.
Confirm the contents match the order — not just the main item but rails, carriers, cables, blanks and licences. The omissions are what delay installations. Our used server guide covers what is usually missing.
Configuration verification
Check what the machine reports against what you bought.
Processors — model and count. Memory — total, and by slot, because the total can be right while the population is wrong. Drives — count, capacity and by bay. Controller — model and whether cache and its battery are present.
The management controller reports all of this without an operating system. Our management guide covers access.
Two things frequently found here: memory populated unevenly, which delivers less bandwidth while reporting full capacity, and a controller cache battery missing or failed, which quietly halves write performance. Our memory install guide and bottleneck guide cover both.
Record the baseline
The step that pays off years later.
Drive hours at arrival. On used equipment this is your reference point for everything afterwards, and it settles later questions about what you were sold.
Drive health values — reallocated and pending sectors, so you know whether later readings have moved.
Firmware levels across BIOS, controller, drives and adapters.
Serials and part numbers of every component, not just the chassis.
Our drive failure guide covers why the baseline matters more than any single reading.
Run it under load
The part that catches what inspection does not.
Sustained load across processors, memory and storage for a meaningful period — a day or more rather than an hour. Transit damage and early-life failures appear under load, not at idle.
Watch temperatures during the test. A machine that throttles under load has a cooling problem, and finding it now is much better than finding it in production.
Check health values again afterwards and compare with the baseline. Anything that moved during the test is a reason to reject the part.
Our burn-in guide covers what a supplier should have done before shipping, and this is the same test at your end.
Before it goes live
Four final steps.
Update firmware in the vendor sequence, and record the levels. Our firmware guide covers the order.
Configure and test remote management from where you would actually need it.
Add it to monitoring before it carries anything. Our monitoring guide covers what to alert on.
Record its rack position and what it runs. Our documentation guide covers why this matters to whoever comes next.
Frequently asked questions
Why test hardware before putting it into production?
Component failures cluster early in life, and the return window is short. Running equipment hard before trusting it moves those failures into a window where they are an inconvenience rather than an incident.
How long should an acceptance test run?
A day or more under sustained load across processors, memory and storage. Transit damage and early-life failures appear under load, not at idle, and an hour is not long enough to surface them.
What should I record when equipment arrives?
Drive hours and health values as a baseline, firmware levels across all components, and serials and part numbers of every component rather than just the chassis.
What is commonly found wrong during acceptance testing?
Memory populated unevenly, which delivers less bandwidth while reporting the full capacity, and a controller cache battery missing or failed, which quietly halves write performance. Neither reports as a fault.
Should I check temperatures during the test?
Yes. A machine that throttles under load has a cooling problem, and finding it during acceptance testing is far better than finding it in production when the workload is slow for no visible reason.
What should happen just before it goes live?
Update firmware in the vendor sequence and record the levels, configure and test remote management from where you would need it, add it to monitoring before it carries anything, and record its rack position and role.
We test before shipping and we expect you to test on arrival. Tell us within the window if anything does not match.
