How to File an ISP SLA Credit Claim: Deadlines, Evidence, Denials & Carrier Credit Procedures

By Michael Obraitis, Managing Partner, and Michael Dale, CEO · Published September 7, 2026 · Last reviewed September 2026 · ADAM Pulse Knowledge Base · Network Operations Series

Short answer

An ISP Service Level Agreement credit is a contractual remedy, not a courtesy and not a refund of what the outage cost the business. The claim succeeds or fails on four facts: whether the event meets the contractual definition of downtime or degradation, whether a required trouble ticket exists for that window, whether the claim was filed inside the product's deadline, and whether the event is excluded.

Independent monitoring is how you know what happened at the customer edge. It is not, by itself, a credit memo. Our companion guide on monitoring an ISP SLA covers measurement. This article covers the claim.

Contractual metrics are not user pain

Cisco describes an SLA as a written agreement based on meaningful and measurable performance metrics. The word that matters is measurable — and measured where the contract says.

Users report: Zoom froze, the pharmacy queue stopped, the VPN dropped, checkout timed out. Those are real. They are also not, by themselves, the SLA.

Public AT&T Internet SLA language is a clean illustration of the measurement-point problem. Network Availability, Network Latency and Data Delivery are defined as aggregate monthly measurements between AT&T POP endpoints on the IP/DSL backbone — MegaPOP to MiniPOP — not as a probe from your firewall to 8.8.8.8. A customer-edge chart can be accurate and still fail that definition.

Public Lumen MSA language makes the other common mismatch explicit: Lumen's maintenance log and trouble-ticketing systems are used to calculate Service Level events. If your monitor saw the gateway drop at 08:42 and the carrier ticket opened at 09:17, the contract clock may start at 09:17.

The evidence pack

File the claim with a package a billing analyst can verify without calling you back for the circuit ID. Collect this during the incident, not the week the invoice arrives.

Claim windows: illustrative, not a tariff

Deadlines are product-specific and they move. The pattern is consistent: there is a notice duty during the event, a later written credit request, and a hard cutoff after which the right is waived. The numbers below are from public documents retrieved 7 September 2026. They are examples of how the industry writes these clocks, not a lookup table for your circuit.

Two clocks hide inside those sentences. A 30 days after the event clock starts on the outage date. A 60 days after the end of the month clock starts on the last day of that month. A 3 March outage under the first rule is due in early April. Under the second, you may have until late May. Do not mix them.

Put the deadline on the incident record the day the circuit restores. Credit claims that wait for the invoice are how 30-day clocks die.

How the claim is actually filed

1. Confirm the product and the document. Dedicated Internet, Ethernet, broadband, wavelength and third-party last-mile are different SLAs. The MSA is not enough; pull the service attachment or service guide for that SKU.
2. Confirm a qualifying ticket exists for the window you will claim. If the contract requires one and you do not have it, the claim is already weak. Do not invent a ticket number.
3. Map the event to the contractual definition. Complete unavailability, latency, jitter, packet delivery, installation interval and restoration-time SLAs are separate claims. File the one the metric supports.
4. Subtract exclusions you can already see: published maintenance, customer power, CPE, a refuse-to-release-for-testing note, force majeure language.
5. Use the channel the contract names. Portal SLA tool, written request to the billing desk, or the support number on the bill. A chat transcript with a tier-1 agent is not always a credit request.
6. Keep the confirmation. Claim ID, submission timestamp, the reporting month you selected, and a PDF of what you uploaded.
7. Watch the next two bills. Public AT&T Internet SLA language says approved credits appear within two billing cycles. If the credit does not post, the follow-up is the claim ID, not a new anecdote.

Why the credit does not match monitoring downtime

This is the argument that wastes the most time, because both sides can be telling the truth.

Argue the contractual definition, not the dollar value of lost orders. The SLA credit is almost never designed to make the business whole. Public AT&T Internet language also caps aggregated monthly credits at one month's MRC for the affected line. Public Lumen language commonly caps monthly credits at that month's charges for the affected Service. Those caps are why a bad month still produces a small credit.

Handling a denial

A denial is a claim about an exclusion or a missing condition. Answer that claim. Do not resend the same chart with a louder subject line.

Escalate on the claim ID, with the clause you are invoking, to the account team or the billing dispute path the contract names. A new severity-1 ticket titled “SLA credit” is the wrong object. Credits are a billing event that points at an already-closed repair ticket.

Filing checklist

Identity — legal name, BAN, circuit ID, product, address. Clock — event start/end with zone labels; claim deadline written on the incident the day it restored. Ticket — carrier ticket opened during the event; internal incident ID. Path — gateway, firewall, LAN, backup WAN each stated. Metrics — the contractual metric, then the chart that matches that metric. Exclusions — maintenance, CPE, power, force majeure checked before you file. Channel — the portal or written path the contract names; confirmation saved. Follow-up — next two invoices; claim ID, not a new story.

Bottom line

SLA credits are a paperwork sport with a technical preface. The technical preface is gateway-first isolation and a ticket opened while the path is actually broken. The paperwork is the contractual definition, the deadline, and a package a billing analyst can verify.

If you only remember one sequence: open the carrier ticket during the event, store UTC timestamps, file inside the product's clock, and argue the metric the contract measures — not the morning the users had.

Frequently asked questions

Related articles

• How to monitor your ISP SLA and hold internet carriers accountable — measurement, availability math and why independent history exists.
• How to prove your ISP is causing packet loss, latency or internet outages — capturing the live-fault evidence the claim later needs.
• Is it the ISP or the firewall? — gateway-first isolation before you attribute downtime to the carrier.
• Network outage communication templates — the customer updates that should sit next to the claim file, not replace it.
• Network outage vs network degradation — why an “up” circuit can still be unusable, and why that may not be a credit.

References

Vendor behaviour and claim windows described here are checked against that vendor's own public documentation rather than secondary coverage. Links verified 7 September 2026. Where this article gives an operating recommendation rather than documented product language, it says so. None of the following is a substitute for the agreement on a specific circuit.

1. AT&T — AT&T Broadband / Business Internet Service Level Agreement (KM1254969)— source for the requirement to notify during a Service Outage, for a Verifiable Trouble Ticket accompanying any credit request, for the 30-day-after-the-event credit request, for credits not being automatic, for the one-month MRC cap, and for Network Availability / Latency / Packet Loss being defined as aggregate POP-to-POP backbone measurements. Page last updated 7 December 2022 at retrieval. Cited as one product family's public SLA, not as AT&T Dedicated Internet or Ethernet.
2. AT&T Business — AT&T Guarantee for Fiber Internet and Wireless— source for the marketing-program rule that a qualifying fiber outage lasting more than 20 minutes may produce a benefit that must be redeemed within 30 days of notice, and for AT&T's statement that the program is not a warranty and does not replace the applicable service agreement. Distinguishing this from the contract SLA is the point of the citation.
3. AT&T — Switched Ethernet Service Guide, Service Level Agreement section— source for the 45-days-after-end-of-month credit request on ASE CoS and Network Availability credits, and for the documented one-credit-per-port-per-month limit on the CoS path. Service-guide language, not a customer-specific order.
4. AT&T — Dedicated Internet SLA Credit Request Quick Guide (BusinessDirect)— source for the existence of an SLA tool path for ADI credit requests and for the published reporting-period picker going back up to three months. A tool guide, not the Service Guide. The contractual deadline still lives in the Service Guide.
5. Lumen — public Master Service Agreement excerpt, Service Levels— source for credits issuing on customer request except for Excused Outages, for Lumen's maintenance log and trouble-ticketing systems being used to calculate Service Level events, for the 60-days-after-end-of-month credit request, and for monthly credits not exceeding charges for the affected Service that month. Public form MSA; a signed customer MSA may differ.
6. Lumen — Service Level Agreement (Qualifying Services)— source for Service Unavailability being defined as the complete inability, other than an Excused Outage, of the customer to deliver IP packets, and for the Excused Outage definition including customer acts or omissions, scheduled maintenance and force majeure. Product SLA, subject to change.
7. Cisco — What Is Network Latency?— supporting source for latency as a measurable performance metric distinct from reachability, which is why an “up” circuit can still miss a latency SLA if the product has one.