Auction Software Reliability: What Actually Matters When the Gavel Is Falling

Every auction platform on earth advertises “99.9% uptime.”

The number is almost meaningless. Spread across a year, 99.9% allows roughly nine hours of unscheduled downtime — and a vendor can deliver that on a Tuesday at 3 a.m. and still hit the SLA. The bad nine hours that actually matter — Saturday at 1:43 p.m., the last sixty seconds of the high-value lot, the moment a live simulcast hits its peak bid — those are not the minutes a generic uptime number measures.

For an auction business, reliability isn’t an annual percentage. It’s the answer to a much sharper question: does the platform stay up the second the gavel is about to fall?

Why 99.9% uptime is the wrong metric

Uptime, as published, is an annual average across the platform’s entire surface area. It typically counts:

1. The marketing site is responding.
2. The bidder login API is up.
3. Some background job is heartbeating.

It rarely counts:

1. Whether bid acceptance latency stayed under one second during a peak.
2. Whether outbid notifications fired within five seconds, every time, every bidder.
3. Whether the live-simulcast video held a stable connection for the duration of the sale.
4. Whether the “place bid” button returned a confirmation, or just spun.

A platform can hit 99.9% on the first list and fail catastrophically on the second. Both can be true on the same Saturday. The annual number tells you almost nothing about the only minutes you actually paid for.

The minutes that actually matter

If you’re running auctions for a living, your reliability picture has roughly three risk windows:

1. The peak-load minute. The last sixty seconds of a high-value lot, when active bidders are refreshing, sniping, and outbidding each other in rapid succession. This is the single highest-stakes minute of your week. It’s also the most common moment for a platform to slow down or jitter.
2. The simulcast hour. If you’re running a live event with online bidders, you have a continuous one-to-three hour window where the video stream, the bid feed, the clerking interface, and the simulcast all have to stay in sync. A failure anywhere in that chain — even a 30-second hiccup — can cost you a hammer price or void a sale.
3. The settlement window. The first 60 minutes after the sale closes, when invoices are generated and bidders are paying. A platform that delays this loses you payments, breaks consignor settlement timing, and creates support volume.

A platform that holds up for all three is reliable. A platform that holds up most of the time, with occasional 90-second hiccups during exactly those windows, is not — even if its annual uptime number reads 99.95%.

Real example: the cattle auction that lost a $32,000 hammer in ninety seconds

A western livestock auctioneer we’ll call Big Sky Cattle Co runs monthly online-and-simulcast bull sales. About 200 active online bidders per sale, roughly $1.4M in gross hammer per event.

One Saturday, partway through their highest-value lot of the night — a registered breeding bull projected at $30K to $35K — the platform’s bid acceptance latency climbed from a steady 600 milliseconds to seven seconds. Bidders started retrying. Confirmation messages stopped arriving. The auctioneer on the floor couldn’t see new online bids fast enough to call them. The lot hammered at $32,000 — almost certainly $4,000 to $8,000 below where it would have closed if the platform had stayed responsive.

The platform’s public status page showed “all systems operational” the entire time. The next monthly uptime report came in at 99.97%. Both numbers were technically true. Neither captured the ninety seconds that mattered.

The vendor’s explanation, eventually, was that a database query optimizer had picked a bad plan during a brief traffic spike. From a reliability-engineering standpoint, that’s a known failure mode. From an auctioneer’s standpoint, it cost real money in the only minute of the night that counted.

“The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.”

— Douglas Adams, Mostly Harmless

Adams’ joke is also a serviceable summary of how most auction-platform outages actually unfold. The systems that fail are exactly the ones the marketing page promised couldn’t. The fix takes longer than expected. And the auctioneer is on the block, in front of bidders, while the engineering team is still figuring out which database is sweating. Reliability isn’t the absence of failure — it’s the speed and humility with which the platform handles failure when it inevitably arrives.

What real reliability looks like

If you’re evaluating an auction platform on reliability — yours or a candidate replacement — go past the uptime number and ask for these:

1. Latency under load, published. Not “fast.” A 50th and 95th percentile latency for bid acceptance, measured during real auction events, broken out by event size.
2. Independent monitoring. A third-party probe (e.g., a public status-page provider) measuring the bid endpoint, not just the marketing homepage. Self-reported uptime is roughly worth what you paid for it.
3. Graceful degradation. If the simulcast video fails, does the bid acceptance still work? If the email service goes down, do the bid records still record? Reliable systems compartmentalize. Brittle ones cascade.
4. Soak testing on peak load. Has the platform been load-tested at 2x or 3x its normal peak? You don’t want to be the test.
5. A real incident postmortem culture. When something fails, do you get a clear writeup with timeline, root cause, and remediation — or a one-line apology and silence? You can read a vendor’s reliability culture in five minutes by reading their last three incident postmortems.

A 5-point reliability audit you can run before your next sale

1. Pull your platform’s last 90 days of incident reports. Are they specific, with timelines and root causes — or vague? Vague is a tell.
2. Time a “place bid” round-trip from a real bidder’s phone, not your office network. Is it consistent under 1 second? Does it spike under load?
3. Ask the vendor: what is your 95th-percentile bid acceptance latency during peak hours? If they can’t answer in numbers, they’re not measuring it.
4. Subscribe to a third-party uptime monitor pinging the bid endpoint, not the homepage. Compare its number to the vendor’s for the next 30 days.
5. Ask the vendor what happens when their video service fails mid-simulcast. The right answer involves the bid layer continuing to function. Any answer that involves the whole sale freezing means the architecture is fragile.

Reliability for an auction business isn’t an annual average. It’s a question with a yes-or-no answer at the only sixty seconds that pay your bills. Pick a platform — and a vendor — that knows the difference.

For how Selling Lane is built around the workflow rather than the marketing page, see how it works or the features overview.