Ah, the classic "we're down but we're not *down*" SLA shuffle. Let me pour out some bitter experience for you.
The difference between a 'service' outage and an 'agent' outage, in the glorious legalese of your typical cloud or SaaS vendor, is the difference between them admitting a global failure and them blaming your specific configuration. It's the architectural equivalent of "the call is coming from inside the house."
Here's the breakdown:
* **A "Service" Outage** means their core platform is broken for *everyone* in a region or availability zone. Think AWS DynamoDB having a bad day in us-east-1, or Google Cloud's Pub/Sub control plane falling over. This is what the SLA is *supposed* to cover. When this happens, they have no wiggle room—it's their fault, and credits (the pittance they are) should be automatically applied.
* **An "Agent" Outage** is their carefully crafted escape hatch. This refers to a failure of a *component you manage* that connects to their service. This is where they get creative. Common culprits they'll shove into this bucket include:
* The lightweight data forwarder you installed on your VMs (a Datadog agent, a New Relic agent, a Logstash shipper).
* The sidecar container in your Kubernetes pod that handles service mesh telemetry.
* The virtual appliance you're running in your VPC to bridge to their SaaS platform.
* Any "connector" software that runs in your infrastructure boundary.
The devil, as always, is in the contractual definitions. You'll often see language like this buried in the exhibit:
```json
"Excluded Downtime" means any period of Downtime arising from:
...
(b) failures of Customer-controlled access networks or dependencies,
(c) failures of the Customer Agent software, or its hosting environment,
(d) performance issues or failures in Customer-submitted configurations.
```
So, your entire application might be blind because their agent has a memory leak and crashes every 30 minutes, but if that agent binary runs on *your* EC2 instance, congratulations—it's an "agent outage." No SLA breach. You get to open a support ticket while your pager goes off.
The practical advice? Before you sign anything that uses this terminology:
1. Demand they explicitly define "Agent" in the contract. What software, exactly?
2. Understand where their responsibility ends. Is it at the API endpoint? At the ingestion queue? The moment the packet leaves your network?
3. For critical services, argue to remove the "agent outage" exclusion for agents that are *mandatory* and provided by the vendor. If you can't use their service without running their blessed agent, its failure should be their problem.
4. Calculate your SLA based on the *service* guarantee only. Assume you'll get zero compensation for "agent" issues, because you will.
They sell you on a 99.95% uptime service, but half the failure modes are neatly categorized under "agent" and excluded. It's a fantastic bit of actuarial engineering—for them.
keep it simple
That's a really helpful way to frame it, thanks. I work mostly with email marketing and HubSpot, so I've seen a version of this from the vendor side. They'll say "it's a deliverability issue, not a platform outage" and then you realize the problem is actually their sending infrastructure being throttled, but they classify it as an agent thing because you're the one who configured the domain authentication.
I guess my question is: for someone like me who isn't deep in the cloud ops side, how do you actually tell the difference in practice? When your dashboard shows red and the support ticket says "agent outage," is there a reliable way to push back and prove it's really a service issue, or do you just have to eat the downtime and hope the credits are worth the argument?
Exactly. And the "agent outage" bucket is where they hide the truly expensive failures. It's rarely your own misconfigured forwarder. More often it's:
* Their proprietary "gateway" VM they make you host (and pay for) in your own cloud.
* Their managed Kubernetes sidecar that stops syncing.
* The mandatory third-party "security" proxy service they resell to you.
Suddenly you're paying for the compute *and* taking the SLA hit. Genius from a vendor margin perspective, infuriating for TCO.
always ask for a multi-year discount
That's a solid list of the technical components that often fall into the agent bucket. The financial angle you mention is key. I've seen this pattern specifically in the BI/reverse ETL space.
One nuance I'd add is that the "agent" designation can also depend on where the configuration surface lives. If a failure is triggered by a setting you can *only* change through their UI or API, even if it's on your infrastructure, some vendors will still try to call it an agent outage. It becomes a debate about control planes versus data planes.
The TCO hit is real because you're now troubleshooting their black-box component on your bill.