The provider has identified the outage. Your team has identified twelve people asking when the system will return.
Both are useful pieces of information. They solve different parts of the problem.
A custom-system support plan needs to cover what the business does while an external provider is investigating. Someone still needs to assess the impact, coordinate decisions and keep affected people informed, even when the technical repair sits elsewhere.
Laravel Cloud’s February 20, 2026 incident report is a useful example of that dependency.1 The provider reported a connectivity outage lasting about three hours and fifteen minutes, linked to withdrawn IP prefix advertisements at Cloudflare. Laravel said its underlying applications and data remained healthy while users could not reach affected services.
Those are the provider’s reported facts. The recommendations below concern how a business can organize its own response to a comparable interruption.
Establish the impact before choosing the remedy
A website failing to load is a symptom. The right response depends on what is unavailable and what is still functioning.
Check the complete business dependency
Determine whether customers, staff or both are affected. Check the application, administration tools and relevant external services, then compare those observations with the provider’s status information.
A network incident can leave background processing running while the customer interface is unreachable. An application error can affect one workflow while the rest of the site remains available.
That distinction matters. Restoring yesterday’s database is unlikely to repair a missing network route. It can, however, introduce an entirely fresh problem, which is rarely the recreational activity anyone had planned.
Put one person in charge of coordination
The coordinator keeps the current picture of the incident and makes sure decisions reach the right people. A technical lead investigates the application and provider dependencies. A business owner decides on operational consequences and any temporary alternative.
Those roles may overlap in a small team. They should still be understood.
Zulu Shack recommends agreeing responsibilities, contact routes and support coverage before an incident. If the arrangement covers defined business hours, the escalation plan should reflect that. A phone number in a proposal does not automatically create continuous availability.
Somebody has to own the quiet, unglamorous work. See our hosting and support plans.
Give people a useful operating plan
During an interruption, uncertainty spreads into everyday work. Staff may wonder whether to accept new orders, repeat failed actions or tell customers to try again.
Communicate what is known and when to check back
An initial update can be brief. It should cover:
- Which service or workflow is affected.
- What the team currently knows and is checking.
- What affected people should do for now.
- When the next update will be provided.
Keep the next-update commitment separate from a restoration estimate. You can usually promise to report what has changed; you may be unable to promise when an upstream provider will finish repairing it.
Use a communication route that remains available if the main application is down. Maintain the same current information there so people do not have to assemble the incident from several optimistic fragments.
Choose a workaround the team can control
A manual fallback can help when it has a defined purpose and the business is prepared to operate it. For a hypothetical booking service, that might mean recording requests for later confirmation, with a clear explanation that availability has not yet been reserved.
The temporary route needs an owner, suitable handling of customer information and a way to distinguish requests from confirmed transactions. It also needs a plan for bringing the records back into the application.
Avoid inviting customers to repeat uncertain payments or submissions until their status can be checked. A stalled screen does not prove that the action failed.
A good workaround should reduce confusion. If it creates a second uncontrolled system, it may simply give the outage a sequel.
If this was useful, try The backup exists. Can you bring the business back from it?
Verify recovery before declaring the day ordinary again
A provider’s recovery notice is a useful signal. The business still needs to establish that its important workflows have returned.
Inspect the work that crossed the interruption
Check representative customer and staff journeys. Review queued activity, delayed callbacks and any transactions whose outcomes were uncertain.
Reconcile temporary records with the application before replaying them. Make sure the people handling support know which items remain unresolved and how affected customers will be contacted.
The final update should distinguish restored service from ongoing cleanup. People can cope with a remaining issue more easily when it is described clearly and someone is looking after it.
Afterward, review the response while the details are fresh. Did the contact routes work? Was the impact clear? Were the temporary decisions useful? Did the support agreement match what the business expected?
The aim is a calmer next incident, with fewer decisions invented under pressure. You cannot personally repair every upstream network. You can make sure the business knows what to do while the people who can are working on it.