Reading a connectivity SLA

Start by identifying what the agreement covers. It might measure the access circuit, a managed device or a broader network service. A working carrier handover does not prove that a customer's wireless network, firewall or cloud application is working. The boundary determines which incidents count and which team must investigate them.

Next, find the measurement period and the definition of unavailable. Does the service need to be completely down, or can severe degradation count? Who measures it, how is evidence reconciled and when does the clock start? A customer report, an automated alarm and the moment the business first notices a problem may be different timestamps.

Consider a purely hypothetical schedule with 99.9% availability measured over a thirty-day month. That month contains 43,200 minutes, so 0.1% is 43.2 minutes. This arithmetic helps interpret the percentage, but it does not promise that an individual interruption will stop after 43.2 minutes. The schedule's exclusions and calculation rules may also change which minutes count.

The distinction matters for multi-site organisations. A branch might tolerate several brief interruptions but not one outage during its trading peak. An aggregate availability measure alone does not describe that operational exposure. Record both the contractual measure and the business consequence of particular outage scenarios.

A response target describes the start of an action, not necessarily a repair. Read what constitutes a response, whether the target applies around the clock and which reporting channel must be used. A ticket acknowledgement and an engineer beginning investigation are not the same event.

Restoration targets concern returning the service, but the wording still matters. Establish whether the time is a target or a guarantee, what stops the clock and whether a temporary repair qualifies. Find out how progress is communicated if the target is missed and who can escalate a prolonged incident.

In a hypothetical comparison, one schedule could offer a fifteen-minute response with a separate restoration target, while another could advertise a shorter response without specifying restoration. The first number does not make either service better by itself. Compare the whole sequence and the hours during which each obligation applies. These examples are illustrative and are not Netavo commitments.

Read planned maintenance, customer-caused faults, access restrictions and other exclusions carefully. An exclusion may be reasonable while still creating an operational gap that the customer must manage. For example, delaying access to a locked communications room can delay repair. Make sure the people who hold keys or authorise entry understand their role before the incident occurs.

Service credits are a contractual remedy, not a substitute for business continuity. Check how they are calculated, any cap, the claim window and the evidence needed. A credit linked to a monthly service charge may be much smaller than the cost of lost trading or staff time. Use that distinction when deciding whether additional resilience is justified.

Build a simple incident plan from the SLA. Record who reports faults, the circuit references, the information support will need and the escalation route. Note when the business will switch to a degraded process rather than waiting for repair. The plan should remain usable when the affected connection is unavailable.

Netavo offers fibre, Ethernet and private WAN connectivity. Assess the proposal for the particular service and location instead of importing a target from another carrier, product or customer installation. Netavo's service targets depend on the access product and carrier and are set out in each order, so read them against your own outage tolerance.

Finally, compare the agreement with the organisation's own tolerance. If a site cannot operate without a connection for longer than its maximum acceptable interruption, a restoration target alone cannot close that gap. Review independent paths, local equipment, power and operational fallback as a separate design exercise. The result should be a documented connection between contract terms, accepted risks and the actions people will take when service is impaired.