Stop the live sequence
Do not sell the active lot, advance the catalog or accept an improvised remote channel while platform state is uncertain.
REFERENCE 06PLATFORM FAILURE RECOVERY
Online Bidding Platform Outage During a Live Auction
Use this runbook when the venue internet still works but the online bidding service, operator console or remote bid path becomes unavailable, unstable or inconsistent during a live sale.
The objective is not to prove who caused the outage. Freeze the live auction state, determine whether the problem is truly platform-side, prevent floor and remote bid sequences from diverging, and reopen only after a complete bidder-to-clerk round trip has been verified.
BUILT FORAuctioneersOperations managersSimulcast operatorsClerksMobile auction crews
OPERATING PRINCIPLE
Protect the bid sequence before you diagnose the platform.
A platform outage is dangerous because the room can look normal while the remote side is no longer trustworthy. The auctioneer may still have bidders in front of them, the clerk computer may still be powered, and general web access may still work. That does not prove that remote bids are arriving in time or that every participant sees the same lot and amount.
Call a controlled hold before staff refresh browsers, sign out, switch accounts or open parallel operator sessions. Record the active lot, last bid that can be independently verified, bidder source, displayed platform state and time. Keep that frozen state visible while the technical lead checks the failure.
The fastest safe recovery is the one that creates one trusted restart state. A fast reconnection that leaves staff uncertain about queued bids, delayed acknowledgements or the last accepted amount is not a recovery.
Capture the last trusted state
Record lot, amount, bidder source, bidder identifier, visible platform state, exact time and who verified it.
Prove the failure layer
Test general internet, another local station and an independent external connection before calling the incident a platform outage.
Run a complete bid test
Resume only when the correct lot is visible remotely, a controlled bid reaches the live operator path and the resulting state agrees across the required views.
Published August 15, 2026 · Prepared by Jasper Auction’s small volunteer community
FIRST 60 SECONDS
Stop the outage from becoming a bid-record dispute.
These steps protect the sale before staff begin platform troubleshooting.
Hold the active lot
Use a neutral pause phrase. Do not call sold, restart from memory or continue floor bidding until the authorized operating mode is clear.
Freeze lot and buyer entry
Stop advancing the catalog. Write down the last result that is fully settled and the current lot that was active when the platform became unreliable.
Preserve the visible platform state
Capture the current lot, bid amount, bidder source, connection indicators and any platform message before refreshing or opening another session.
Stop uncontrolled changes
One person directs tests. Avoid simultaneous browser restarts, account swaps, hotspot changes and new operator sessions.
FAILURE CLASSIFICATION
Platform outage, internet outage or workstation failure?
Choose the runbook from the failed layer, not from the first error message that appears.
| Observed state | Most likely layer | First proof | Use this page? |
|---|---|---|---|
| General internet and unrelated web services work, but the auction platform fails across more than one device. | Platform or service path | Test the platform from a second local station and an independent external connection. | Yes — continue with the platform-outage sequence. |
| Multiple internet-dependent services fail on the production network. | WAN, LAN, DNS or venue network | Compare the production WAN with an approved independent connection. | No — move to the Internet Outage Runbook. |
| One clerk or simulcast computer fails while the same auction remains healthy on another approved station. | Local workstation, browser or application | Open the same live sale on the tested spare and compare state. | No — use the Clerking Computer Failure runbook when the clerk role is affected. |
| The platform loads, but remote bids arrive late, duplicate, queue unexpectedly or disagree with the clerk view. | Platform transaction or synchronization path | Freeze the bid state and compare platform history, operator view and clerk record. | Yes — treat the bid path as untrusted until reconciled. |
PLATFORM-SIDE SIGNALS
Look for the same failure through independent paths.
A single frozen browser proves very little. A platform-side incident becomes more plausible when two or more approved stations, or a local station and a separate external connection, show the same unavailable service while unrelated internet access remains healthy.
Do not use a public status page as the only proof. Status dashboards can lag the first reports of an incident, and a regional or account-specific fault may not appear immediately. Your own controlled tests determine whether the production bid path is safe to use.
If only one user, browser profile, workstation or ring is affected, isolate that narrower fault before moving the entire auction into outage mode.
Operator console unavailable
The production operator view cannot load or repeatedly returns a service-side error on separate approved paths.
Lot or bid state disagrees
The bidder view, operator console and clerk record no longer show one consistent active lot or last accepted amount.
Bids do not complete normally
Remote bids appear delayed, stuck, duplicated, rejected without clear cause or acknowledged differently across views.
Several known-good sessions fail together
Separate approved operator or bidder sessions fail in the same service while local network tests remain healthy.
RECOVERY SEQUENCE
Recover the platform path without creating a second live auction.
The order matters more than the speed of any one technical fix.
- 01
Hold the active lot and stop accepting remote bids
Make the pause visible to the room and operations team. Do not allow staff to collect remote bids by text, personal phone or another unsanctioned channel.
- 02
Write the last trusted auction state
Record the sale, ring, lot, amount, bidder source, bidder identifier, time and the last action that can be verified from two independent observations or records.
- 03
Prove general connectivity still works
From the production network, test one unrelated internet service needed for diagnosis. Avoid broad browsing that creates noise or unnecessary traffic.
- 04
Compare another approved local station
If a second production-capable station reaches the live auction normally, treat the incident as a local workstation, browser, account or application problem rather than a platform outage.
- 05
Compare an independent external connection
Use an approved device or connection that bypasses the venue network. Confirm only what is necessary: can the platform be reached, can the correct sale and ring be loaded, and is the same fault visible?
- 06
Contact platform support with a clean incident summary
Provide event or sale ID, ring, first affected time, error behavior, local versus external test result and the last trusted lot. Keep the support case or incident reference with the sale record.
- 07
Keep one production operator path
Do not leave several staff members signed into competing operator sessions. If an alternate approved station is used, name it as the active station and isolate the old session.
- 08
Reconcile the last pre-outage bid state
When service returns, compare the restored platform history with the clerk record and the frozen incident note before allowing the auctioneer to restart the lot.
- 09
Run one complete bidder-to-clerk test
Use an approved test account or defined test procedure. Verify sale, ring, lot, bid submission, operator receipt, acknowledgement and the resulting clerk-side state.
- 10
Resume from one announced restart state
The auctioneer repeats the lot and current amount, the clerk confirms the record, the platform operator confirms the remote path and the authorized decision owner authorizes the restart.
BID-STATE RECONCILIATION
Do not assume the last visible bid was the last accepted bid.
During a service interruption, an operator screen may freeze before the underlying platform stops processing, or a bidder action may leave the bidder device without a clear acknowledgement. Preserve the pre-outage screenshot or written state, then compare it with the platform history that appears after recovery.
If the restored platform, clerk record and preserved state disagree, keep the lot paused and escalate through the auction’s documented bid-discrepancy procedure. Technical staff should present evidence; they should not decide the commercial or legal outcome of a disputed bid.
END-TO-END PROOF
Test from the bidder side, not only from the operator desk.
A successful operator login proves that one screen can reach the service. It does not prove that a bidder can see the correct lot, submit a bid, receive acknowledgement and create the expected state at the operator and clerk positions.
The recovery test should use the same critical path as the live sale. Confirm the correct sale and ring, verify the active lot, submit one controlled action through the approved test method, follow it to the operator or clerk and confirm that the expected response returns to the bidder side.
Remove or clearly mark test activity according to the platform’s approved procedure before reopening live bidding.
Reach the correct sale
Confirm event, ring, catalog and user permissions before testing anything that could alter the live record.
Confirm the active lot
The bidder and operator views must show the restart lot and expected current state.
Complete one controlled action
Follow the approved test method through submission, receipt and acknowledgement rather than relying on page-load success.
Confirm one shared result
The bidder view, operator view and clerk record must agree before live bidding is released.
REDUCED OPERATING MODE
Define floor-only continuation rules before the outage.
Do not invent a reduced participation rule after remote bidders have already entered the sale.
| Condition | Default decision | Required control | Why |
|---|---|---|---|
| The sale terms and operating plan explicitly permit floor-only continuation after a defined remote outage. | Possible reduced mode | Use the named authority, announcement, lot boundary and record required by the pre-sale plan. | The participation rule existed before the incident and can be applied consistently. |
| Remote participation is material to the sale and no reduced-mode rule was defined. | Remain paused | Escalate to the authorized sale decision owner. | Staff should not remove a bidder channel ad hoc during live competition. |
| Platform state is uncertain and queued or delayed bids may still exist. | Remain paused | Reconcile platform history and the last trusted bid before taking another bid. | A new floor bid could overtake an unresolved remote action. |
| The platform returns and one operator can log in, but end-to-end bid testing has not passed. | Remain paused | Complete the bidder-side round trip and restart-state briefing. | Access to the console does not prove the transaction path. |
COMMUNICATIONS
Use short language that does not guess at the cause.
Keep technical diagnosis out of the public announcement until the failure has been verified.
“Bidding is temporarily paused.”
Tell the room that the online participation path is being verified and that the active lot remains held until the auctioneer announces the restart.
“The online bidding service remains unavailable.”
State that the auction remains paused while the team verifies the platform and bid record. Say when the next update will be given, when practical.
“The online path has been verified.”
Repeat the lot and current bidding state before taking a new bid. Do not resume with only a generic “we are back.”
Use only approved sale language
If the pre-sale plan allows a different participation mode, use the exact authorized wording and document the lot boundary where the mode changed.
RESUME / REMAIN PAUSED
Reopen only when one restart state is shared by every critical role.
The platform returning is necessary, but it is not sufficient proof of recovery. The auctioneer must know the lot and amount, the clerk must have one trusted sale record, the operator must have one active platform session, and the technical lead must have proved the complete bid path.
Read the restart state aloud inside the team before the public restart. If the first live remote bid after reopening reaches the wrong lot, arrives unexpectedly late or creates a different state on the clerk and platform views, pause again immediately.
Do not troubleshoot the old production session in parallel with the live replacement. Keep one named operator path until the ring is stable.
| Condition | Decision | Required action |
|---|---|---|
| Correct sale, ring and lot load; controlled bidder action reaches the operator and all required views agree. | Resume | Record the verified restart state, brief the team and reopen from the announced lot and amount. |
| Platform login works, but bidder-side transaction testing has not passed. | Remain paused | Complete end-to-end verification. |
| Restored platform history disagrees with the frozen pre-outage record. | Remain paused | Preserve both states and reconcile the disputed bid sequence. |
| The first live bid after reopening appears on the wrong lot or arrives with an unexpected delay. | Pause again | Return to the recorded restart state and isolate the synchronization problem. |
MINIMUM INCIDENT RECORD
Keep enough evidence to reconstruct the platform gap.
The incident note should remain usable even if the affected online service is inaccessible.
Sale, ring and active lot
Event ID, ring, lot, catalog position, last trusted bid, bidder source and exact time the platform became unreliable.
Local and independent checks
Record whether general internet worked, whether another local station failed and whether an external connection reproduced the platform problem.
Platform case reference
Keep the support case, status message or incident reference with the sale record, but do not wait for a public incident notice before protecting the auction.
Verification and resume authority
Record the successful end-to-end test, the time live bidding resumed, the named decision owner and the first live lot after recovery.
Printable platform outage incident record
Keep a paper copy at the simulcast desk or download the plain-text version for the backup workstation.
ONLINE BIDDING PLATFORM OUTAGE — INCIDENT RECORD SALE / EVENT: _____________________________________________ RING: ___________________ PLATFORM: _____________________ OUTAGE DETECTED: __________ ACTIVE LOT: __________________ LAST VERIFIED BID: _________________________________________ BIDDER SOURCE / ID: ________________________________________ LOCAL INTERNET: PASS / FAIL SECOND STATION: PASS / FAIL EXTERNAL TEST: PASS / FAIL SUPPORT CASE: ______________ RESTORED PLATFORM STATE: ___________________________________ END-TO-END BID TEST: PASS / FAIL RESUME TIME: ____________ RESUME AUTHORITY: _______________
PRE-SALE PREPARATION
Test the recovery path while the platform is healthy.
A backup login or spare laptop is useful only if staff know exactly how it fits into the live sale.
Prepare an approved alternate operator path
Verify the spare workstation, browser profile, credentials, permissions and the exact sale and ring that must be opened.
Define an independent bidder test
Know which device, connection and approved test method will prove the complete transaction path without improvisation.
Store support details offline
Keep the account or event identifiers and support route available outside the platform interface.
Decide reduced mode in advance
Define who can authorize a pause, floor-only continuation, postponement or restart and what announcement must be made.
FAQ
Common questions during an online bidding platform outage.
Use these answers as operational defaults; the auction’s own sale terms and platform procedures remain the controlling local documents.
How can staff tell a platform outage from an internet outage?
Confirm that the production internet path can reach independent services, then test the auction platform from another local station and, when available, from an independent external connection. If general internet access works but the same auction service fails across separate devices or connections, a platform-side failure becomes more likely.
Should the auctioneer keep taking floor bids while online bidding is unavailable?
Not automatically. If remote participation is part of the published sale and the team cannot determine whether remote bids are queued, delayed or missing, continuing floor bidding can create an unfair or disputed sequence. Use the pre-approved reduced-mode rule or remain paused.
Is refreshing the bidding browser a safe first step?
No. First preserve the active lot, last trusted bid, bidder source and visible platform state. A refresh, logout or new session can remove useful evidence or cause staff to lose the last reliable view of the sale.
Can staff switch to another platform account or browser during the outage?
Only through a documented and tested recovery path. A second session must be opened on the correct sale and ring with the intended permissions, and it must not create competing operators or conflicting writes.
What if the platform comes back but shows a different last bid?
Remain paused. Preserve the pre-outage record and the restored platform state, then reconcile the difference using platform history, clerk records and the authorized sale procedure before accepting another live bid.
What proves that the platform is ready to resume?
A complete test should reach the correct sale, ring and lot from an independent bidder-side path, arrive at the operator or clerk, receive the expected acknowledgement and leave the required views synchronized.
Should platform support be contacted before any local testing?
Contact support early when a platform-side failure is suspected, but do not wait to protect the sale record. Freeze the active state first, then gather concise test results that support can use without making uncontrolled production changes.
What should be tested before the next auction?
Rehearse the exact pause phrase, platform-status check, alternate operator login, independent bidder test, support escalation path, incident log, restart-state briefing and the rule for floor-only or reduced-mode continuation.
OPERATING RULE
Do not resume because the platform loads. Resume because the bid path and auction record agree.
A live bidding service can reconnect before staff know what happened to the last bid. The safest restart begins with the preserved lot and amount, proves the bidder-to-clerk transaction path, reconciles any conflicting state and gives one person authority to reopen the sale.
REFERENCE / PLATFORM FAILURE
Back to Reference ↗Keep this runbook at the simulcast desk.
Pair it with the internet-outage and clerking-computer procedures so staff can choose the correct failure path without guessing under sale-day pressure.