WordPress Downtime Cost: A 90-Minute Incident Worksheet

WordPress downtime cost is a worksheet with separate columns, not one rupee total. Gross sales at risk is the order value a normal pace implies during a failed checkout window. Contribution margin is only the share of that same value left after goods and payment fees. Support expense is the cost of extra contacts. Recovery labor is the cost of the people who work the incident. Deferred purchases stay apart because some buyers may still order later. Adding those columns as independent losses counts the same orders more than once. The 90-minute case below is a labeled illustration with stated assumptions and units. It is not a measured Adiba customer incident.

Editorial review date: 10 October 2026. The original publication date is unchanged.

What a WordPress downtime cost worksheet keeps apart

The columns stay apart because the units do not mix. Orders per hour, rupees per order, a contribution ratio, contacts, minutes of technician time, and a return rate on deferred carts each answer a different question. One unlabeled total hides which question was asked.

Gross is a scale figure. Contribution is calculated from that gross, so the two are not independent losses. Support and recovery labor are operating costs of the incident, not slices of the sales line. The return rate is an assumption about later orders, not cash already received. Add unrecovered contribution to support and labor only after the split. Do not add gross to contribution, and do not add gross again to a total built from contribution.

Illustrative inputs and units

The table is the input sheet for this illustration. Every row is an assumption or a figure derived from assumptions, and the unit sits in its own column. The contribution ratio of 0.35 is the share left after goods and payment fees. It is not net profit after rent, salaries, advertising, or tax. None of the rates is a published price or a measured Adiba incident.

Input	Illustrative assumption	Unit	Label
Orders per hour	40	orders per hour	Assumption, not a measured Adiba incident
Incident length	90	minutes, equal to 1.5 hours	Assumption
Orders at risk	60	orders	Derived from 40 per hour times 1.5 hours
Average order value	4500	PKR per order	Assumption
Contribution ratio	0.35	share of gross after goods and payment fees	Assumption, not net profit
Support tickets	25	extra contacts	Assumption
Minutes of technician time	12 each, 300 total	minutes	Assumption, 25 times 12
Internal support rate	700	PKR per hour	Assumption
Recovery labor	3 people, 2 hours, 900	people, hours, PKR per person-hour	Assumption
Assumed return rate of deferred carts	50 percent	share of contribution that might arrive later	Assumption, not a counted return

If the hourly order count is wrong, every rupee figure downstream moves with it. Keep a hoped-for return rate labeled as an assumption.

Arithmetic for the hypothetical 90 minutes

Normal pace is 40 orders per hour across 90 minutes, or 1.5 hours. Orders at risk equal 40 times 1.5, which is 60 orders. Gross sales at risk equal 60 times 4500 PKR, which is 270000 PKR. That 270000 is the illustrative value implied by the pace. It is not money already missing from a bank account, and it is not a measured Adiba customer incident.

Contribution at risk equals 270000 times 0.35, which is 94500 PKR. The ratio already removes goods and payment fees from those same 60 orders. The 94500 is not an extra pile of sales, and it is not profit after overhead. You must not add 270000 and 94500 together. That sum would be 364500 and would count the same orders once as gross and again as margin.

Support is a different unit. 25 contacts at 12 minutes each equal 300 minutes of technician time, which is 5 hours. At 700 PKR per hour, 5 times 700 equals 3500 PKR. That 3500 is illustrative support expense. It is not inside the 94500.

Recovery labor is 3 people times 2 hours times 900 PKR per person-hour, which equals 5400 PKR. Those 2 hours can run past the customer-facing window, because a gateway export and a payment match often continue after checkout responds. The 5400 is internal labor, not a vendor invoice and not part of gross sales.

The deferred column is the uncertain one. Assume 50 percent of contribution might still arrive later. Half of 94500 is 47250, so unrecovered contribution is about 47250 PKR. Leave the other 47250 out of the loss column. Do not also take an abandoned-cart percentage off gross, or the same uncertainty is counted twice.

Add only unrecovered contribution, support, and labor: 47250 plus 3500 plus 5400 equals 56150 PKR. That 56150 excludes the half that may return and excludes goods and payment fees. It must not be added to 270000, because it was derived from that gross. Until the shop replaces the 50 percent return rate, both 47250 and 56150 stay assumptions, not a customer result.

Incident ownership

One named person holds the clock, the change log, and the decision to stop further changes. The clock starts when checkout or payment confirmation fails for buyers. It stops when new orders complete and match the gateway, not when a status page turns green. During the illustrative 90 minutes, only that owner may approve a restore, a plugin change, or a public message. Others may gather evidence. The log records the minute, the action, and the result. Later reconciliation reads that log.

If the shop uses enterprise WordPress, the owner still decides when a platform action may touch production, and which files and database a restore includes. A provider can run the restore only after the owner names the backup. If the shop uses pro support, that channel can read logs and an order export. It does not replace the person who says whether the shop is taking money again. Write the names while the shop is calm. "Whoever is online" is not an owner. One person may cover two seats if the sheet says so.

Transaction reconciliation

When the window ends, the 270000 gross figure is still a pace estimate. Reconciliation puts records beside it. Export captured, authorized, and failed gateway attempts for the same 90 minutes, and export shop orders for the same clock, including pending and failed rows. Match amount, time, and reference. Paid in both places is value that landed. Paid at the gateway with no order is a fulfillment or refund debt, not a second gross loss beside 270000. An order with no capture is the candidate for money the shop did not take.

WooCommerce describes high-performance order storage as dedicated order tables, rather than order data living only in the general post tables. The match has to read those tables when the mode is on. That design is not a capacity promise, and it does not make a 90-minute failure smaller. Confirm plugin and theme compatibility on a copy before any mode change. Do not switch storage mode during the incident, or the export gains a second unknown.

Keep the illustrative 60 orders and the counted captures in separate cells. Do not average them. Lock the sheet after the gateway cutoff. A later chargeback is a new dated event. Replace the assumed 25 contacts with tickets before treating 3500 PKR as more than a worked example, and decide whether repeat chats from one buyer count once or several times. Those contact figures are assumptions, not a measured queue.

Restore readiness

A finished backup job is not a restore. The WordPress page on backups treats files and the database as copies kept so a site can be moved or restored. Files plus database means uploads, themes, and plugins together with the database of orders, users, and settings. Files alone leave orders behind. The database alone leaves the media and code those rows expect. A complete status does not prove that checkout can take a payment.

Drill on a non-production copy. Restore the latest pair, look up a known order, and place a small test checkout in a sandbox or a blocked test mode. Record the minutes and the person. If the drill runs much longer than 2 hours, change 3 people times 2 hours times 900 before repeating 5400 PKR. Know the backup timestamp, because payments after that time come back only through the gateway export. Name the backup, the target, and the incident owner who may promote the restore. Test order-storage compatibility on a copy before a campaign, not during the restore itself.

Prevent, detect, and recover with a named owner

Prevention, detection, and recovery are different work, and each action in the table needs an owner from the shop. The rows are generic. They are not a measured incident, and they do not claim to remove downtime. Fill the owner column before treating any rupee cell as more than an illustration.

Phase	Action	Owner
Prevent	Time a files-plus-database restore on a copy and record the minutes	Incident owner
Prevent	Confirm order-storage compatibility on a copy before any mode change	Technical owner
Prevent	Pause campaign edits while checkout is the path that takes payment	Campaign owner
Detect	Start the incident clock when checkout or payment confirmation fails	Incident owner
Detect	Compare shop orders with gateway attempts for the same minutes	Reconciliation owner
Recover	Approve one restore candidate and keep a change log	Incident owner
Recover	Answer extra contacts from one status note and count them	Support owner
Recover	Match captured payments to orders and lock the sheet after cutoff	Reconciliation owner

If detect has no name, the 90 minutes can start late and the orders-per-hour math covers the wrong span. If recover has several people and no incident owner, two restores can conflict. If prevent has no dated drill, the 2-hour labor assumption has nothing behind it.

What to replace before the next campaign

You must not add 270000 and 94500 together. The illustrative sum of unrecovered contribution, support, and labor is 56150 PKR, and it is not a measured Adiba customer incident. Fill the input sheet with the shop's own hourly order count before the next campaign. Then replace average order value, the contribution ratio, support contacts, minutes of technician time, labor rates, and the assumed return rate of deferred carts.