A website outage is easy to notice. The more expensive interruption can be less visible: staff cannot sign in, an order stops between two systems, or the only person with the recovery credential is unavailable. Downtime is a business-process problem before it is a server problem.
For an Australian small business, the useful question is not what a global survey says an hour of downtime costs. It is what your business cannot do, what work is lost and how long a safe recovery takes. This guide helps you estimate that exposure without pretending every interrupted visit was a guaranteed sale.
Start with the service people actually need
List the tasks that generate income or keep commitments: taking orders, answering calls, invoicing, accessing customer records, delivering booked work and receiving enquiries. A service can be impaired even when its homepage responds. A broken payment integration or inaccessible sign-in route may stop the task that matters.
business.gov.au’s emergency management guidance separates continuity planning, immediate action and recovery. Its template asks businesses to identify important services, customers, infrastructure, contacts and information backups. Use that structure rather than starting with a shopping list of spare equipment.
Separate the costs before adding them
There are at least four useful categories: contribution from sales that are genuinely lost, paid time spent unable to work, direct incident and recovery expenditure, and later reconciliation or customer-support effort. Record them separately so the same loss does not appear twice.
Gross sales are not the same as contribution. Some interrupted orders are completed later, some customers use another channel and some would not have purchased anyway. Estimate a range, state the assumptions and distinguish permanently lost business from deferred work. An alarming single number can make the wrong upgrade look inevitable.
For staff time, record who was affected and what productive alternatives were available. Do not count the full payroll as lost and then count the same recovery hours again. For a sole operator, include unpaid evening recovery work, but label the value you assign to that time as an estimate rather than a cash invoice.
A simple worked example
Suppose an illustrative two-hour interruption leaves four people unable to complete their usual tasks. You estimate eight affected person-hours at an internal value of $40 an hour, or $320. A separate technician invoice is $250, and you estimate $200 in contribution from orders that will not return. That scenario totals $770 before later reconciliation.
Those are invented inputs to demonstrate the method, not industry benchmarks or a SenseICT client result. If the staff instead completed other useful work, reduce the time cost. If the orders were recovered later, remove that contribution loss. The point is an explainable model you can update with real evidence.
Recovery time and data loss are different targets
Your restoration target asks how long the service can be unavailable. Your data-loss target asks how much recent information can be lost or recreated. A backup from yesterday might restore the website quickly while leaving today’s orders missing. A recent backup may still take hours to retrieve, validate and deploy.
Write both requirements in plain language before selecting a backup schedule or a more complex platform. The small-business recovery checklist translates them into accounts, files, dependencies and a testable procedure.
Recovery includes validation. Confirm that the right records are present, forms and payments work, and restored integrations do not resend old messages or duplicate charges. A server booting successfully is not the same as the business being safe to resume.
A backup is only useful with access and a tested restore
ASD’s technical guidance on regular backups recommends testing restoration and considering how data and configuration are recovered. Keep copies and access arrangements suited to the risks, rather than relying on a successful job notification alone.
Check who can retrieve the backup if the main account is compromised, how credentials are recovered and whether the procedure depends on the failed platform. Keep an appropriate recovery copy of the runbook and critical contacts available elsewhere. Protect it: a continuity plan should not become an unencrypted collection of administrator passwords.
Your domain and email ownership matter here. If you cannot change DNS or receive a recovery message, a replacement server may be ready but unreachable. Include identity, DNS, certificates and third-party accounts in the dependency list.
Availability claims do not describe your whole business
A provider’s uptime commitment applies to the scope and exclusions in its agreement. It may not cover your application, an external payment service or a plugin update. Read the contract and distinguish a response target, restoration target and service-credit remedy. A credit is not automatically compensation for the business impact.
The hosting procurement guide helps assign maintenance and recovery responsibilities. The Australian hosting guide explains why server location does not settle the complete continuity question.
Redundancy can help, but it also creates operating work
A second server may reduce one failure mode while leaving the same database, identity account or deployment error shared by both. Document the dependencies before calling the design resilient. Test how traffic moves and how writable data stays consistent.
Use the VPS, containers and Kubernetes guide to compare complexity with operating capacity. The right answer may be a simpler service with a fast, tested rebuild rather than a cluster nobody can confidently maintain.
Safe automation can make restoration repeatable, but it needs stop conditions, useful logs and a human escalation route. Automating an uncertain recovery procedure makes it fail faster, not more safely.
Communication is part of continuity
Decide how customers will be informed if the normal email, phone or website is unavailable. Keep the message factual: what is affected, any usable alternative and when the next update will appear. Avoid promising a restoration time without evidence.
Keep incident updates separate from promotional content. The Australian spam-law guide explains why adding an offer can change the character of a service notice. Do not treat an outage as an excuse to market to every contact.
Turn the estimate into a proportionate plan
- Choose the critical business tasks and their dependencies.
- Estimate a plausible interruption using separate cost categories.
- Set restoration and acceptable data-loss targets.
- Assign owners, access and escalation contacts.
- Test recovery in a safe environment and record actual time.
- Fix the largest gap, then test again.
- Review after major application, supplier or staffing changes.
A small business does not need to buy enterprise infrastructure to take continuity seriously. It needs a plan that matches its exposure and works when someone is tired, under pressure or unavailable. Contact Matt at SenseICT if you want help mapping the dependencies and turning the recovery procedure into something testable.
Featured photograph: imgix / Unsplash. Illustrative stock image, not SenseICT’s facility.
