4.6VIEW ALL RATINGS
NETWORKONLINE
0
01 / STORE

HARDWARE
LIVE CATALOG.

SHA-256, Scrypt, Equihash, Blake3, and Ethash ASICs — buy, rent, or host on RAR rails.

VIEW ALL HARDWARE↗
BITCOIN · SHA-256U3S23H1,160 TH/s · HYDROS23 XP HYD. 600T600 TH/s · HYDROS21 XP+ HYD. 480T480 TH/s · HYDROS21 XP 270T270 TH/s · AIR
ALTCOIN · OTHERL11 HU633 GH/s SCRYPT · LTC / DOGEZ15 PRO840 KSol/s · ZECAL1 PRO16.6 TH/s · ALPHVIEW ALL →FULL HARDWARE CATALOG
FEATURED SYSTEMBITCOIN MINER
U3S23H
1160TH/s
VIEW SYSTEM →
02 / MARKETPLACE

BUY.
SELL. TRADE.

A hardware marketplace for miners, operators and infrastructure providers.

ENTER MARKETPLACE↗
DISCOVERALL LISTINGSLIVE HARDWARE INVENTORYNEW LISTINGSRECENTLY ADDEDVERIFIED SELLERSTRUSTED OPERATORS
SELLSELL HARDWARELIST YOUR MINERBULK LISTINGMULTIPLE MACHINESSELLER DASHBOARDMANAGE INVENTORY
MARKET LIVE
1,284ACTIVE LISTINGS
RAR / SEARCH SYSTEM
ESC
01HARDWARE STORE02MARKETPLACE03RENT A RIG04MINING HOSTING
← ALL GUIDES
RAR / OPS GUIDE · ADV · ~11 MIN

UPTIME
& CREDITS.

Uptime credits are how Rent A Rig makes facility downtime your economic problem only when it is actually the facility’s fault. You cannot control grid events, cooling failures, or rack power loss inside a RAR hall — credits realign incentives when the SLA window is missed. They are not insurance against bitcoin price, pool luck, or your own configuration errors. This chronometer guide covers what counts, what does not, how rental versus hosted credit math differs, how to file with evidence while logs still exist, and how to read the outcome on your statement or term.

UTCINCIDENT WINDOWAMBER = CREDIT SLICE
CANONICAL CLOCK/STATUS INCIDENT POSTSOfficial windows drive credit math — not chat memory.
CREDIT DOCTRINE

RELIEF FOR HALL FAULTS.
NOT FOR OPERATOR FAULTS.

When the plant fails you, the ticket should be about recovery and credit — not about pretending configuration mistakes are facility events. When your worker string is wrong, the ticket should be about fixing the string — not about minting a credit. Keep that split honest and both Support and the SLA program move faster. During any suspected facility event, System Status is the canonical surface: incident posts define the official UTC window used for credit math. Screenshot your telemetry against that window; do not wait for a perfect narrative to appear in chat.

COUNTS

FACILITY
DOWNTIME.

Power loss to the bay or rack, cooling failure that forces a safety shutdown, network backbone loss inside the facility, or scheduled maintenance that overruns the published window without notice — these are the core inclusion set. Partial degradation, such as reduced hashrate from thermal derate during an extreme event, may count depending on the incident note on /status. If the status post names your neighborhood and your telemetry goes dark or derates inside that UTC window, you are in credit territory until Support says otherwise with a reason.

POWER — Bay or rack loses feed for reasons inside the hall’s responsibility, not because you unplugged a fantasy breaker at home.

COOLING — Safety shutdown from facility thermal failure, documented on the incident chronometer.

BACKBONE — Facility network loss that takes allocations offline even when your pool credentials are correct.

OVERRUN — Maintenance that escapes its published window without notice, turning planned work into unannounced downtime.

DOES NOT COUNT

OPERATOR
AND OUTSIDE.

Wrong pool or worker config, account 2FA lockouts, client-side VPN issues, intentional offline for firmware experiments, and seller-side marketplace delays are outside facility credits. Self-hosted machines shipped to you — not sitting in a RAR bay — are outside facility credits entirely, because the plant you are not using cannot owe you an SLA. File those problems as Support or marketplace cases, not as uptime credit claims, or you burn desk time and weaken the signal when a real hall event hits.

CONFIG — Flat hashrate with healthy power almost always means pool or worker strings, not a silent PDU failure.

ACCESS — 2FA and VPN problems live on your side of the account boundary.

EXPERIMENTS — Intentional offline for firmware work is a choice, not an SLA breach.

SELF-HOST — Machines at your site never inherit hall credits; your power and your ops own that risk.

CONTRACT LEDGERS

RENTAL CREDIT ≠
HOSTED CREDIT.

The same hall event can touch both products, but the economic instrument differs. Know which ledger you are on before you argue about what “make whole” means.

TWO INSTRUMENTS
LEDGER / RENTRENTALS

Credits typically apply against rental fees for the affected allocation and window. Because power is bundled into the rental service, the credit is about the service you paid to run — time and allocation — not about inventing a separate kilowatt-hour rebate on a bill that never itemized power that way. When a PDU neighborhood goes dark, the math asks how much of your paid rental window was facility-dark, then adjusts fees or term accordingly per policy.

TARGET · RENTAL FEES / TERM WINDOW
LEDGER / HOSTHOSTED FLEETS

Credits typically apply against hosting power and ops charges for the affected kWh or SLA shortfall — not against the capital cost of your ASIC. Title stays yours; the facility failed the service wrapped around the steel. A credit will not repurchase your machine or invent hashrate insurance against price. Pair this with Hosting Basics so SLA targets on bay, rack, and pod stay in the same mental model as the credit ticket.

TARGET · POWER / OPS CHARGES · NOT CAPEX
EVENT → CREDIT CURVE

THE WINDOW IS THE
UNIT OF MATH.

Illustrative only: green traces service health; amber marks the credit-relevant slice when status declares an incident. Your claim should map telemetry to that UTC window — not to a feeling that “it seemed down all week.”

UPTIME TRACE · CREDIT SLICE OVERLAY ILLUSTRATIVE
SERVICE HEALTH CREDIT-RELEVANT WINDOW
FILING PACKET

OPEN SUPPORT WHILE
LOGS STILL EXIST.

Save the incident ID from /status, your rental or asset ID, and telemetry screenshots showing the outage. Open Support with subject line UPTIME CREDIT. Do not wait weeks — most programs require prompt notice so facility logs still exist. Separate config issues from facility issues before you claim; a clean packet gets a clean desk response.

FIELD 01INCIDENT WINDOW (START / END UTC)

Copy the official times from the status post. If your telemetry starts earlier or ends later, note both — desk correlates; you do not invent a wider window alone.

FIELD 02AFFECTED MACHINE CODES

Rental IDs or hosted asset tags that sat on the impacted path. Partial approvals happen when only part of a fleet sat on the impacted PDU — list what you actually had online there.

FIELD 03TELEMETRY PROOF

Screenshots or exports showing the dark or derated interval aligned to UTC. Power-flat-with-hash-zero patterns should be called out as possible config so you do not burn the claim.

FIELD 04CONTRACT TYPE

State rental versus hosting clearly so the ledger instrument is obvious on first read. Mixed fleets need both called out per machine, not as a single vague “my ops.”

READING THE OUTCOME

STATEMENT LINES.
NOT VIBES.

Approved credits appear as account balance adjustments or term extensions — the ticket close note will say which. Partial approvals are normal when impact was neighborhood-scoped. Credits are capped by the service fees tied to the affected window and contract; they do not exceed fees paid. Major facility incidents may auto-list affected accounts, but you should still verify and file if your unit was hit and not listed.

LINEMEANINGYOUR CHECK
BALANCE ADJ.Credit posted against fees for the affected windowConfirm on next statement cycle
TERM EXT.Rental or service window extended in lieu of cash-like creditConfirm new end date on the allocation
PARTIALOnly machines on the impacted PDU or row were coveredReconcile IDs against the close note
DENIED · CONFIGEvidence pointed at operator-side causeFix strings; do not refile the same gap as SLA
OPS TAPE

DURING ANY SUSPECTED
FACILITY EVENT.

STATUS — Follow /status for the canonical UTC window and incident ID before you write a novel in Support.

SNAPSHOT — Capture telemetry and machine IDs immediately so the packet exists while the outage is still on the glass.

FILE — Open Support with UPTIME CREDIT in the subject and the four fields filled; prompt notice protects log retention.

SEPARATE — Split config issues from facility issues before you claim so the desk is not debugging your worker name inside a credit queue.

CONFIRM — Watch the next statement or term for posting, and reconcile partial approvals against the close note IDs.

OPS FAQ

QUESTIONS AFTER
THE LIGHTS FLICKER.

ARE CREDITS AUTOMATIC?

Major facility incidents may auto-list affected accounts, but you should still verify and file if your unit was hit and not listed. Automation is a head start, not a guarantee that every neighborhood edge case was tagged. Your packet is the backup that keeps a missed row from becoming a shrugged shoulder.

CAN CREDITS EXCEED FEES PAID?

No. Credits are capped by the service fees tied to the affected window and contract. The program realigns incentives around what you paid for the service that failed — it does not mint speculative hashrate insurance or repurchase hardware.

DOES MAINTENANCE COUNT?

Published, in-window maintenance usually does not. Overruns or unannounced maintenance can. Read the status note: if the desk published a window and finished inside it, that is planned work you were told about. If the window slipped without notice, you are back in credit-relevant territory.

WHERE DOES WARRANTY FIT?

Warranty covers defect and hardware paths; uptime credits cover facility service shortfalls. They can appear in the same week without being the same instrument. When in doubt, file clearly labeled tickets rather than blending both into one ambiguous thread — see warranty for defect scope and keep UPTIME CREDIT in the subject for SLA math.

NEXT

WATCH THE WALL.
FILE WITH PROOF.

SYSTEM STATUSSUPPORTHOSTINGWARRANTYALL GUIDES