Data Doesn’t Have Uptime. It Has Consequences

I was just starting in the rock-and-roll lifestyle of enterprise data when managed service providers (MSPs) started selling storage as a service (STaaS) in the early 2000s. Their innovative approach to developing it was something enterprise IT has been successfully avoiding ever since. 

What did those MSPs realize? You can’t sell a service without defining what happens when you fail to deliver it, and it couldn’t be cloaked in vague contractual language or the comfortable ambiguity of “best effort.” The service required accountability to the granularity of measurable numbers like recovery windows, throughput commitments, and IOPS targets scoped to a specific block size and read/write ratio. 

These MSPs developed data services tiers not for philosophical ideals but for practical business reasons—customer contracts required clear, quantifiable performance commitments.

Interestingly, a question emerged from that arrangement that enterprise IT has never really had to answer: What is this data actually worth?

The absence of that question is why most enterprise storage SLAs are, functionally, fiction.

The siren’s song of the traditional measurement trap

Traditional systems performance measures infrastructure variables like uptime percentages, mean time to repair, and incident response windows, which are reasonable metrics for a world where the main goal was simply keeping servers running as discrete, identifiable systems that were either on or off and online or down. The problem is, today’s enterprise has evolved and doesn’t run exclusively on servers. It also runs on data platforms that support interconnected workflows spanning ingestion pipelines, analytics engines, AI training jobs, and customer-facing applications. And, all of those depend on data moving with consistency and speed across environments.

In that conventional measurement world, infrastructure can be technically “up” and still be functionally failing. For instance, if an AI training pipeline stalls because storage throughput degrades under concurrent load, the uptime metric would still stay green. Or, an analytics job misses its window because the data tier it depends on is sharing headroom with a workload that wasn’t supposed to be there, but every SLA threshold of availability is technically satisfied. Even worse, a customer-facing inference service slows to the point of abandonment due to a chaos of competing storage requests, but the dashboard shows 99.9%. All of these scenarios are plausible with traditional metrics of measuring uptime.

Paul Neuman, Head of GTM Services at IT Services Demystified, put it plainly in The Data Wire: “If your SLA isn’t tied to business impacts like revenue risk, data availability, and customer experience, it’s just a technical promise. Modern agreements have to quantify operational resilience, not just uptime.”

The MSP world understood this by necessity, and enterprise IT understood it mostly in hindsight and usually during a post-mortem after the business outcome had already failed.

So what is the pivot for modern data center operations? The answer isn’t to abandon SLAs, but to build them around data, not infrastructure and with the brutal standardization that the service provider model demands with the monitoring infrastructure to make the commitments enforceable.

Standardization is not a bad thing

There’s a reason MSPs limit their service tiers. It’s a business decision. Every tier you add is a separate cost model you have to maintain, a monitoring policy you have to enforce, a support escalation path you have to staff, and a per-GB price you have to justify. The real discipline isn’t in defining the tiers, it’s in resisting the temptation to create 17 of them to avoid the hard conversation about which workloads actually matter. Remember the core maxim that we like to fool ourselves as IT professionals into thinking isn’t true… everything matters equally as much, even if it doesn’t.

A defensible data services SLA framework is built around four tiers, with each grounded in the business consequence of failure and not the technical elegance of the spec. Here’s a sample list:

Platinum: Mission critical

• IOPS: 100,000 (8K block size, 70/30 read/write)
• Throughput: 1GBps
• Latency: ≤ 150μs average; p99 ≤ 1ms
• RTO: Sub-minute
• RPO: Sub-minute
• Cloud reference: Azure Ultra Disk—sub-millisecond latency, up to 400K IOPS

This is the tier for workloads where failure has immediate revenue consequences: transaction processing, real-time decisioning, and the AI inference pipelines your customers interact with directly. The 150-microsecond average latency target isn’t arbitrary—it’s a threshold where storage latency stops being a variable in application performance and becomes invisible to it. Cross that line in the wrong direction and you’re not debugging a storage problem; you’re explaining a business outcome and a potential resume-generating event.

Gold: Business critical

• IOPS: 50,000 (8K block size, 70/30 read/write)
• Throughput: 512MBps
• Latency: ≤ 500μs average; p99 ≤ 5ms
• RTO: Under one hour
• RPO: Under one hour
• Cloud reference: Azure Premium SSD v2 — sub-millisecond latency, up to 80K IOPS, 1,200 MBps

This tier is for analytics platforms, ERP systems, and AI training workloads that don’t face customers directly, but inform them. Failure here isn’t catastrophic in the moment, but the ripple effects compound quietly until it boils over. Miss enough Gold-tier RPOs and your business starts running on stale data without anyone noticing until the quarterly review, at which point the conversation becomes considerably more uncomfortable. 

Silver: Business necessary

• IOPS: 25,000 (8K block size, 70/30 read/write)
• Throughput: 256MBps
• Latency: ≤ 2ms average; p99 ≤ 15ms
• RTO: Four hours
• RPO: Eight hours
• Cloud reference: Azure Premium SSD v1—up to 20K IOPS, 900 MBps

A silver tier is for internal collaboration platforms, development environments, and staging areas for data pipelines that feed Gold-tier analytics. These workloads won’t generate an incident report, but consistently treating them like a lower tier will erode developer velocity and pipeline reliability in ways that are real, cumulative, and nearly impossible to attribute after the fact.

Bronze: Low priority

• IOPS: 5,000 (8K block size, 70/30 read/write)
• Throughput: 256MBps
• Latency: ≤ 20ms average; best effort p99
• RTO: 24 hours
• RPO: 24 hours
• Cloud reference: Azure Standard SSD/Standard HDD—up to 6K IOPS, best-effort latency

This tier is for “cooler” data like archive, backup targets, and compliance repositories. This is all data that has to exist, but doesn’t need to be fast. Bronze isn’t a punishment tier; it’s an honest accounting of what “low priority” actually means in performance terms, and what that honesty saves you in cost per GB compared to treating everything like it might be mission critical (a very common thing).

This is important—the glass to break here is in the classification and not the tiers themselves. Chances are good that most organizations, if they’re honest, have Platinum data sitting on Silver infrastructure or everything all on two tiers defined as “fast” and “slow.” This is because nobody ever had the conversation about what it was worth, and nobody built the monitoring framework to find out. Again, this is a server uptime mentality misapplied to data services.

The ingredients to shift from storage management to data management

This is where the Everpure strategic repositioning vision begins to emerge… not as a brand exercise, but as a new product thesis. The rebrand from Pure Storage to Everpure tracks directly with the SLA problem. Founder and CTO Coz said in a press release that our new and evolving capabilities will look inside the data to understand what is actually in it, which is precisely what enables data management and governance, rather than just storage management. That’s not a pivot for its own sake… it’s the recognition that tier-based data services SLAs are only enforceable if the platform can see the data, classify it, and apply a policy to it automatically. And, not as a one-time configuration exercise, but continuously, as the data moves across every environment it touches.

In practical terms, this is the problem that Everpure Fusion™ was built to solve, not by adding another management layer on top of a fragmented “portfolio” estate, but by serving as the universal control plane that federates every array in the fleet—FlashArray™, FlashBlade®, and cloud—into a single policy-driven environment where provisioning, enforcement, and workload placement happens globally, rather than array by array. You cannot enforce a Platinum SLA on a workload your infrastructure cannot reach as a unified whole, and Everpure Fusion is the mechanism that closes that gap. Policy automation and central reporting aren’t optional components in a tiered data services model… they’re the reason tiers become enforceable rather than aspirational, and without them, the framework is a taxonomy exercise with excellent slide design for the bosses.

Pure1® is the intelligence layer that makes Everpure Fusion actions defensible by aggregating telemetry across the entire environment, performance, capacity, risk, and workload health, while returning placement guidance and optimization recommendations that Everpure Fusion can act on autonomously. The relationship matters for tier enforcement specifically because if Everpure Fusion is the “hands,” Pure1 is the “brain,” and together they form the intelligent control plane that closes the gap between knowing which workload is at risk and actually doing something about it before the SLA window expires.

Our 1touch acquisition extends the stack further still by adding crucial functionality like data discovery, semantic context, and classification across any environment to unlock data value for AI use cases. The question sitting at the heart of every tier model of “what tier does this data actually belong in?” becomes something the platform can increasingly autonomously answer, without requiring a manual audit or a heated conversation between the storage team and the application owners.

And if you want to support the tier model delivered not as an operational framework you build and maintain yourself, but as a commercially contractual service with guarantees attached to it, that’s Evergreen//One™. There’s a detail in the Evergreen//One Product Guide that calls a specific tier variable out: its guaranteed performance SLAs are anchored to a 70:30 read/write workload baseline, which is the same workload model that underpins the tier framework I described above. That alignment isn’t cosmetic; it’s the proof that the tier model and the service were built on the same intellectual foundation. 

Evergreen//One Adaptive Tiers takes it further still by decoupling capacity from performance so organizations can scale each independently as workloads evolve—eliminating the overprovisioning tax that comes from treating every tier like it might become Platinum on a bad day. You define the service outcomes: IOPS, throughput, latency, and footprint. The rest is up to us to deliver them under that SLA and backed by 99.9999% uptime, a 25% capacity buffer, and a 28-day deployment guarantee.

The hardware is also included, which matters a lot more than you think. Most (if not all) Everpure competitors offering storage as a service are assembling subscriptions around commodity off-the-shelf SSDs, which means their financial flexibility is constrained by someone else’s supply chain and someone else’s margins. 

Everpure builds its own DirectFlash® Modules as purpose-built flash storage devices that bypass the inefficiencies of commodity SSDs entirely and manage the NAND directly through the Purity storage operating system rather than through the disk controller and flash translation layers that add latency, cost, and complexity. DirectFlash Modules run two to five times more efficiently than the COTS SSDs that support competing STaaS offerings. That efficiency gap is what gives Everpure the financial flexibility to include hardware in the subscription at terms our competitors structurally cannot match. When a service guarantee includes the physical infrastructure and the company building that infrastructure controls its own hardware economics, the SLA suddenly doesn’t look like a marketing commitment—it’s an engineering one. The managed services world built the concept out of necessity, and Everpure built the product.

Uptime isn’t enough anymore. It’s time for enterprises to move to tiered data services, SLAs, and XLAs that align storage performance with real business consequences.

Experience level agreements (XLAs) are an emerging set of metrics that measure whether the platform delivered the experience users and business workflows expected, and not whether the infrastructure was up, but whether the business outcome was achieved. These are things like AI model training completion time, data pipeline reliability, developer provisioning velocity, and customer transaction success rates. And while this idea seems like SLAs dressed up in a new suit, XLA metrics are necessary to capture what a technically available system can still silently fail to deliver—how the business is operationally affected by slow pipelines, missed windows, and degraded customer-facing performance that never technically trigger an “outage” but still erode revenue, productivity, and trust.

Unfortunately, there’s a frequent logic gap in most XLA conversations that often gets missed. You cannot measure experience outcomes without a data services SLA foundation that defines what “good” looks like at the infrastructure layer first. XLAs without SLA tiers are aspirations without accountability—you’re measuring whether the diner enjoyed the meal without any prior agreement about what the kitchen was supposed to deliver. The SLA tier model doesn’t constrain the XLA; it gives the XLA something to prove.

The Platinum-tier commitment listed above with sub-minute RPO, 100,000 IOPS, and 1GBps throughput produces a concrete XLA expectation like inference latency below a threshold that keeps the customer engaged, pipeline completion rates high enough that model development doesn’t slip, and transaction success rates that the revenue forecast actually assumed. The SLA defines the floor, and the XLA measures whether that floor held under the weight of the actual business functions running on top of it.

This reframe matters for enterprise leaders building data platforms in the AI era. The traditional infrastructure question of “did the system stay online?” is merely table stakes now and not a success criterion. The real measurement is whether the data platform delivered the outcomes the business was counting on. And you cannot answer that question with any confidence until you’ve priced the true operational risk in the first place.

A tough conversation worth having

Trying to bring tier classification order to data center chaos is a Herculean task. Classifying workloads into tiers forces an organizational reckoning that most enterprises would rather not have. Asking hard questions like: “What does this data actually cost us when it’s unavailable, degraded, or slow?” The answer is often uncomfortable because it usually reveals the misalignments that have been accumulating quietly for years. These are things like a mission-critical ERP that’s been running on Silver-tier infrastructure because nobody wanted to fund the upgrade, an AI training pipeline that keeps slipping because it’s sharing throughput with a Gold-tier analytics workload on the same array, or a 24-hour RPO on a data set that drives next-day customer decisions.

The MSP world was forced to have this conversation because cash was on the line, and a misstep on a managed contract was expensive and visible. Enterprise IT usually doesn’t have that forcing its function and support… unless it builds one.

Data doesn’t have uptime—it has consequences. And the SLA tier model is how you standardize and design things honestly, which is by workload, with the monitoring and policy automation to make the practice stick. The XLA is how you prove, quarter after quarter, that the platform underneath the business is delivering something more valuable than the absence of a function or incident.

Ready to have the SLA/XLA conversation? If you’re wondering where your workloads actually sit in a tier framework like this, or what it would look like to have those SLAs guaranteed rather than aspired to, talk to an Everpure expert.