How to Measure Business Internet Uptime and Hold Your ISP to Their SLA

Your internet provider promises 99.9% uptime. It sounds like an ironclad guarantee. But when your connection drops at 9am on a Tuesday and you are losing sales, fielding staff complaints, and fighting with a helpdesk queue, that number feels very different. The question is not just whether your ISP will honour their Service Level Agreement — it is whether you have the data, the process, and the understanding of the contract to make them do so.

This guide walks through what uptime SLAs actually promise, how to monitor your connection independently, and what it takes to lodge a credible credit claim when your provider falls short.

What "Uptime" Actually Means

Uptime is the percentage of time a service is available over a defined measurement period — typically a calendar month or rolling 30 days. The calculation is straightforward: available time divided by total time, expressed as a percentage.

What is less obvious is what those percentages mean in practice. Here is the maths.

A 99% uptime guarantee sounds very close to perfect. But 1% of a year is 3.65 days — over 87 hours of potential downtime annually that sits entirely within the SLA. A 99.9% commitment reduces that to 8.77 hours per year, or roughly 43 minutes per month. At 99.95%, you are looking at 4.38 hours per year. Only at 99.99% does the number become genuinely impressive: 52.6 minutes of allowable downtime across an entire year.

Most Australian business internet SLAs — including services delivered over the NBN and standard fibre products — promise 99.9% or 99.95% uptime. The 99.99% figure is typically reserved for dedicated enterprise connections, leased lines, and high-end Ethernet services that carry a significantly higher monthly fee. For the majority of Australian businesses, the realistic SLA means your provider can leave you without internet access for nearly nine hours in a given year and remain entirely within the terms of the agreement.

That framing matters. A business evaluating SLAs should read "99.9% uptime" not as near-perfect reliability but as a commitment to keep allowable outage time below 8.77 hours per year. Understanding this is the foundation for everything else covered in this guide. For a deeper look at how Australian business internet SLAs are structured, see our overview of business internet SLA terms in Australia.

What SLAs Cover and What They Exclude

The fine print of an ISP's SLA typically defines uptime in a very specific and limited way. Most providers measure availability at the network port at their point of presence — the point where the provider's network hands off to the access network. This is not the same as end-to-end availability at your premises.

That distinction has practical consequences. If your router fails, that is not an SLA event — it is a customer-side fault. If a third-party application your business depends on (a cloud accounting platform, a payment gateway, a VoIP system) is unavailable due to a problem on the application provider's end, that is not an SLA event either. If your connection is technically "up" — data is passing — but performance is so poor that the connection is functionally unusable, that may or may not be an SLA event depending on whether the contract includes performance thresholds alongside availability commitments.

Standard exclusions in Australian ISP SLAs include scheduled maintenance windows (the provider is typically required to give notice but the downtime does not count against their uptime target), force majeure events such as natural disasters, power outages, or major infrastructure incidents beyond the provider's control, and any outages attributable to the customer's equipment, configuration, or actions.

This last exclusion is worth paying attention to. A misconfigured router, a failed power supply in the comms room, or a staff member accidentally disconnecting equipment can all cause an outage that looks, from your perspective, like an ISP failure — but will not result in an SLA credit. Before lodging any claim, it is important to confirm that the fault originated with the provider's network, not your own infrastructure.

The Three Types of Downtime Your ISP Counts

Not all internet problems are equal, and SLAs treat them differently.

The first type is a complete outage: the connection is fully unavailable, no data is passing. The WAN link is down. This is the clearest category for SLA purposes, because it is binary — the connection is either up or it is not. Most SLAs are written to capture this cleanly, and it is the easiest type of fault to document.

The second type is partial degradation: the connection is technically available but performance is substantially below what has been contracted. This includes severe packet loss, sustained high latency, or speeds that are a fraction of the agreed service level. Partial degradation is where most SLA disputes start. A well-structured SLA will define explicit thresholds — for example, latency above a specified value for more than a defined period, or packet loss above a certain percentage — and include these within the availability metric. Many SLAs do not. If your contract does not define what constitutes an "unusable" connection, claiming a credit for degraded performance is considerably harder than claiming for a complete outage.

The third type is intermittent connectivity: the connection drops and reconnects repeatedly over an extended period. This is the hardest to measure and the hardest to claim against. An outage of 30 seconds every 20 minutes might never trigger a monitoring alert if the alert threshold requires sustained downtime, but across a working day it adds up to real disruption. ISPs often argue these events are within normal operating parameters. Your strongest defence is detailed logs that capture every drop, including timestamps and durations, so you can calculate cumulative downtime rather than presenting a series of individual events that each fall below the threshold.

How to Monitor Your Internet Connection

Independent monitoring data is the foundation of any SLA claim. Without it, you are relying entirely on your ISP's own records to confirm that an outage occurred — and those records may not reflect your actual experience.

There are three levels of monitoring appropriate for different business contexts.

Level 1 — Cloud-based ping monitoring

For most small and medium businesses, a cloud-based monitoring service is the right starting point. Tools such as Uptime Robot, StatusCake, and Freshping operate by pinging a target IP address or URL at defined intervals — typically every one to five minutes — from external servers. When the target becomes unreachable, the service triggers an alert via email or SMS.

These tools are inexpensive (several have free tiers) and require no hardware. The limitation is that they detect outages from the outside: they confirm that your monitored endpoint is unreachable from the internet, but they do not run from inside your network. This is generally sufficient for documenting complete outages, and the monitoring data — logs showing when the endpoint became unreachable and when it recovered — provides useful supporting evidence for a claim.

Level 2 — On-premises monitoring

A more detailed picture comes from monitoring software or hardware installed inside your business network. This can be a dedicated device or software running on an existing server that performs continuous tests from inside the LAN: ping tests to external and internal targets, traceroute diagnostics, speed tests at regular intervals, and latency measurements. Tools in this category include Domotz and Obkio, or a low-cost device such as a Raspberry Pi running open-source network monitoring software.

On-premises monitoring captures what is happening at your end of the connection. It can distinguish between a fault in the access network (the last-mile connection between your premises and the provider's exchange) and a fault on the customer's own equipment. It also captures performance data — latency, packet loss, speed — that is relevant for claims involving degraded connections rather than complete outages.

Level 3 — Router-level logging

Most business-grade routers maintain connection logs that record when the WAN link transitions between up and down states. Routers from manufacturers such as Draytek, Peplink, Fortinet, and Ubiquiti all support this functionality, though it typically requires configuration to ensure logs are retained for long enough to be useful — default retention periods can be short. If your router's logs only go back 48 hours, they will not help you reconstruct an outage from three weeks ago when you are ready to submit a claim.

Configure your router to log WAN interface state changes with timestamps, and either export those logs to a syslog server or ensure the retention period covers at least 60 days. Router logs are particularly valuable because they sit inside your network and record events that external monitors may not capture with precision — for instance, the exact second a connection dropped rather than the one-to-five minute polling window of a cloud service.

Across all three levels, the key data to capture for any outage is the start time, the end time, the total duration, and the frequency if the fault is intermittent. For guidance on appropriate router and firewall hardware for business connections, see our guide to business routers and firewalls in Australia.

How ISPs Measure Uptime (and Why It Differs from Yours)

ISPs measure uptime from their own network management systems. These systems monitor the state of network equipment, interfaces, and routing — but they do so from the provider's side of the network, not from inside the customer's premises.

This creates a structural gap. A fault in the access network — the physical or wireless connection between your premises and the provider's exchange or point of presence — may cause a complete outage from your perspective while the provider's systems show the core network as healthy. The last-mile segment is often the most failure-prone part of the connection, and it is also the segment least likely to be automatically visible to the provider's internal monitoring. In these cases, the provider may not even be aware of your outage until you report it.

There is an inherent conflict of interest in ISPs self-reporting their own SLA performance. This is not necessarily bad faith — most providers are not actively misrepresenting their uptime — but the measurement methodology means the provider's uptime figures will almost always be better than the customer's actual experience. Your independent monitoring data, taken from inside your network, is a more accurate record of what you experienced. The challenge is that ISPs are not contractually obligated to accept your monitoring data as definitive — the SLA will typically specify how uptime is measured and that specification will reference the provider's own systems.

This is where fault reference numbers become important. Every time you report an outage to your provider, request a fault reference number and record it. This creates an entry in the provider's own fault management system — a record that exists within their infrastructure and that they cannot later dispute. When you submit an SLA credit claim, the fault reference numbers associated with reported outages are your link between your independent monitoring data and the provider's internal records. Without them, you are presenting your data against their silence.

How SLA Credits Work in Practice

SLA credits are the contractual remedy when a provider misses their uptime commitment. The mechanics are fairly consistent across Australian ISPs.

Credits are calculated as a proportion of the monthly service fee for the period of downtime, with a maximum cap. A common structure is: downtime in hours divided by total hours in the month, multiplied by the monthly fee — and typically capped at one full month's fee. Some providers use a tiered structure, with larger credits for longer outages.

The critical point that many business owners miss is that SLA credits are almost never applied automatically. You must claim them. The provider will not review their own records, identify that you experienced an outage exceeding the SLA threshold, and proactively apply a credit to your account. The obligation is on the customer to identify the breach, calculate the credit, and submit a formal claim.

The claim process typically requires a written request — email is preferable to phone because it creates a dated record — specifying the dates and times of each outage, the duration of each, the fault reference numbers obtained when you reported them, and the specific SLA clause you are invoking. Most providers set a submission deadline, commonly within 30 days of the end of the month in which the outage occurred. Missing that deadline can void the claim entirely, regardless of how well documented it is.

For businesses on NBN-based products, SLA credits are often modest in absolute terms. A full month's credit on a $200/month service is $200. For a business that was fully inoperable for eight hours, $200 may bear no relationship to the actual cost of the disruption. Dedicated enterprise connections, which carry higher monthly fees and stricter uptime commitments, provide proportionally larger credits — and the credit is more likely to reflect something close to the business impact. For more on the difference between shared and dedicated connections, see our comparison of dedicated versus shared business internet in Australia.

When SLA Credits Are Not Enough

SLA credits are compensation for the service fee, not for business losses. The SLA sits within a contract that is almost certainly limited to service credits as the exclusive remedy — your provider's liability is capped at refunding what you paid them for the period of the outage. If your business lost $10,000 in sales because EFTPOS was unavailable for four hours, or because your team could not access cloud-hosted systems, or because a scheduled video call with an important client failed, you will not recover that from a $200 credit.

For businesses where internet connectivity is operationally critical — where downtime has a direct and quantifiable impact on revenue, productivity, or compliance — SLA credits are the wrong frame. The right frame is redundancy: a backup connection that takes over automatically when the primary fails, ensuring that no single fault results in a complete loss of connectivity. A secondary 4G/5G failover connection, a second fixed-line service from a different provider using a different access technology, or a bonded connection that aggregates multiple links all provide resilience that a credit note cannot. For a detailed look at redundancy options for Australian businesses, see our guide to business internet redundancy and failover.

Beyond redundancy, review your SLA for escalation provisions. A well-structured enterprise SLA will include the right to escalate a fault to a dedicated management team if it is not resolved within a specified time, and may include additional remedies for repeated failures — for example, the right to exit the contract without penalty if the provider misses the uptime target for two or more consecutive months. If your current contract lacks these provisions, it is worth raising them at renewal.

If SLA performance has been consistently poor and the provider is unresponsive to claims, switching providers is a legitimate option. The process for changing business internet providers is more involved than a residential switch but not prohibitively complex, and the disruption of a planned migration is typically far less than the accumulated disruption of a service that repeatedly fails. Our guide to switching your business internet provider in Australia covers the process in detail.

Setting Up an SLA Claim: A Practical Checklist

When an outage occurs, the actions you take in the first hour are the ones that will determine whether a credit claim succeeds. Here is what to do.

Record the start time immediately. The moment you notice the connection is down, note the time. Do not wait until after the fault is resolved. This timestamp, logged independently of your ISP, is the beginning of your evidence chain.

Determine whether the fault is with your equipment or the provider's network. Reboot the router and check whether the WAN link recovers. If you have a secondary internet connection or mobile data, check whether nearby businesses are affected. Check your provider's status page and outage notification channels (many providers post to a status page or social media during network incidents). If the fault appears to be on your equipment, address that before calling the provider — this step prevents you from logging a fault reference for a customer-side issue, which can complicate future claims.

Call the provider and request a fault reference number. Do not hang up until you have it. If the agent cannot provide one immediately, ask for a case ID, ticket number, or incident reference — any unique identifier that allows you to reference the fault later. If you contacted support by phone, follow up in writing (email or the provider's ticketing portal) to create a paper trail.

Document everything in writing. Email is more reliable than phone for this purpose. Send yourself a timestamped email noting the outage start time, what you observed, and the fault reference number. Update it when the connection is restored. This creates a contemporaneous record that is difficult to dispute.

Check your contract for the credit claim process and deadline. Locate the SLA section of your service agreement and identify the claims process, the required information, and the submission deadline. Most providers require claims within 30 days of the end of the month in which the outage occurred.

Compile your evidence and submit the claim in writing. Your claim should include the outage dates and times, the duration of each event, the fault reference numbers, your independent monitoring data (screenshots or exported logs from your monitoring tool and router), and a citation of the specific SLA clause you believe was breached. Keep a copy of everything you send.

How Pickle Approaches Uptime and SLA

Pickle provides business phone and internet services to Australian businesses, with documented uptime commitments and proactive fault monitoring built into the service. Rather than waiting for customers to report faults, Pickle's monitoring means network issues are frequently identified before they reach customers — and when faults do occur, the response process is clear and the team is accessible.

If your current business internet service is not meeting its SLA, or if you are reviewing your connectivity options for better reliability and clearer accountability, the Pickle team can walk you through what is available for your location and requirements.

Call 1300 688 588 or email [email protected] to speak with the team.

Frequently Asked Questions

Q: How do I prove my internet was down to claim an SLA credit?

A: The strongest evidence is independent monitoring data captured outside your ISP's own systems. This includes logs from a cloud-based uptime monitoring tool (such as Uptime Robot, StatusCake, or Freshping), on-premises monitoring software, and WAN state logs from your business router. You should also have the fault reference number issued when you reported the outage to your provider, along with a written record of when the fault started and when it was resolved. Presenting your own timestamped data alongside a fault reference from the provider's own system gives you the most credible basis for a claim.

Q: What tools can I use to monitor my business internet uptime?

A: The simplest starting point is a cloud-based monitoring service such as Uptime Robot, StatusCake, or Freshping, all of which offer free tiers and will alert you by email or SMS when your monitored endpoint becomes unreachable. For more detailed diagnostics, on-premises tools like Domotz or Obkio run from inside your network and capture performance data including latency and packet loss. Your business router almost certainly maintains WAN connection logs — configure it to retain sufficient history and export logs to a syslog server if you need long-term records. The right level of monitoring depends on how critical connectivity is to your business operations.

Q: Does my ISP automatically compensate me when I have an outage?

A: In almost all cases, no. SLA credits are not applied automatically. The customer is responsible for identifying when the SLA has been breached, calculating the credit entitlement, and submitting a formal written claim within the timeframe specified in the contract — commonly within 30 days of the end of the month in which the outage occurred. If you do not claim, you will not receive a credit, regardless of how significant the outage was.

Q: What is the difference between 99.9% and 99.95% uptime?

A: The difference is approximately 4.4 hours of allowable downtime per year. A 99.9% SLA permits up to 8.77 hours of downtime annually (around 43 minutes per month). A 99.95% SLA reduces that to 4.38 hours per year (around 22 minutes per month). In practical terms, both commitments allow for multiple outage events in a year before the provider is in breach. The 99.95% figure provides a tighter commitment and may also indicate a higher-grade service with faster fault response times — but the specific credit and response terms in the contract matter more than the headline percentage alone.

Q: Can I claim SLA credits if my internet is slow but not fully down?

A: It depends on your contract. Some SLAs include performance thresholds — defining minimum acceptable speeds, maximum latency, or maximum packet loss — and treat a connection that breaches these thresholds as a partial or full SLA event. Many standard business NBN SLAs do not include performance thresholds and only cover complete unavailability. If your connection is slow but technically "up," review your contract carefully for any performance commitments. If none exist, you may have limited grounds for a credit claim, but you should still report the fault to create a record and explore whether the provider can identify and resolve a technical cause.