Professional website maintenance services
in Cambridge

Every support inbox fills up with a mix of problems that look alike in a ticket list but are not alike at all. A checkout that stops accepting payments and a label that is spelled wrong both arrive as one line in an inbox. They are not the same problem. Without a severity framework, the loudest message wins attention, not the issue that actually threatens the business.

A severity framework sorts incoming problems into a small number of tiers before anyone decides how fast to respond. A typical structure has four levels. A full outage or data loss sits at the top, above a major function broken for many users, a minor function broken for some, and a cosmetic or low-impact issue. Each tier carries a different expectation for how fast someone looks at it, and how fast it gets fixed.

Response and resolution are not the same promise. Mixing them up causes most of the friction between a support team and a client. Response is the time it takes for someone to acknowledge a ticket and start looking. Resolution is the time it takes to actually fix the problem or ship a workaround. A critical outage might get a ten minute response and a same day resolution. A cosmetic issue can wait two weeks for the same fix.

Assigning severity is a judgment call. Context decides everything. The person making that call needs enough of it to avoid two common mistakes. The first is letting the reporter set the severity, since a frustrated user will call almost anything critical. The second is applying a rigid definition that misses business impact, such as treating a broken signup form as minor because it technically still loads, when it silently blocks every new lead coming through it.

Escalation is what happens when the first person to see a ticket cannot resolve it inside the expected window. A defined escalation path names who gets pulled in next. A senior engineer covers a technical dead end. A specialist covers a third party integration. The account lead steps in when the relationship itself needs attention. Without that path, a ticket sits with one person who is stuck, and the clock keeps running unnoticed.

Escalation should also run in the other direction. Once a fix ships, the same chain that raised the alarm should confirm the problem is actually gone. Ideally, that confirmation comes from the person who reported it, or from a monitoring check covering the same symptom. Closing a ticket on the assumption that a deploy worked, without checking the original symptom, is how the same issue comes back a week later under a new ticket number.

Severity definitions age. Nobody updates them on their own. A tier that made sense when a product had a few hundred users can misclassify problems once it starts handling real money for thousands of them. A support agreement should set a scheduled point, such as a quarterly review, where the definitions themselves get checked against how the product and its user base have changed. Keeping the categories current matters more than keeping an exact count of tiers.

The clearest sign that a severity framework works is not the speed of any single response. It is the absence of surprises. Nobody on the business side is shocked that a critical bug moved fast while a cosmetic one waited, because the rule was set and shared before either ticket arrived. Nobody argues about it in the middle of an incident.

Backups and disaster recovery get treated as the same thing. They are not. A backup is a copy of data taken at a point in time. Nothing more. Disaster recovery is the full plan for getting a product back to a working state after something destroys or corrupts more than data: a server, a region, a piece of infrastructure the product depends on.

Two numbers anchor a disaster recovery plan, and both need to be set on purpose rather than left implicit. Recovery point objective is how much data a business can afford to lose, measured in time: an hour of transactions, a day of form submissions. Recovery time objective is how long the business can tolerate being down before the cost of the outage turns serious. A plan built without agreeing on these numbers first tends to over-invest in one and quietly ignore the other.

A backup that has never been restored is an assumption, not a safeguard. Restoration should be tested on a schedule rather than only after something goes wrong. The first real test of a recovery plan should never be the actual disaster. A quarterly restore into an isolated environment, checked against a short list of things that must look right, catches a broken backup while there is still time to fix the process.

Different failures call for different recovery paths. One size does not fit all here. Treating every incident as one scenario leads to a plan that only covers the easy case. A single corrupted table can often be repaired from a recent backup in minutes. A failed server needs a rebuild from infrastructure code or a documented manual process. A failure at the hosting provider itself, rare as it is, needs a plan that does not assume the provider will be reachable to help.

Dependencies outside the product itself are often the part a recovery plan forgets. A payment processor, an email delivery service, a search index, a third party login provider: each can fail on its own, and each failure needs its own fallback behavior defined in advance. Sometimes that behavior is simply a clear message to the visitor rather than a silent error.

Roles matter as much as steps. Who is authorized to declare an incident? Who communicates with affected users? Who holds the access credentials needed to act? A recovery plan that lists technical actions but skips these questions tends to stall in the first ten minutes on matters that have nothing to do with the technical fix.

None of this needs to be elaborate for a small or mid-size product. A short written plan, a tested backup, a named decision maker, and a documented list of external dependencies cover most real incidents. The plan does not need to survive a scenario the business will never face. It needs to survive the ones that actually happen, and those tend to be smaller and more mundane than the term disaster recovery suggests.

Reviewing the plan after any real incident, however small, keeps it honest. The gap between what the plan assumed and what actually happened during a real outage is the best source of what to fix before the next one.