Most data teams either ignore SLAs entirely or apply them to everything. Both approaches fail. Service Level Agreements (SLAs) are not reliability guarantees, but they help data teams have difficult conversations that data engineers might otherwise avoid. They are expectation management tools. That’s why I’ve only met a few data teams that have reached this level of maturity.
SLAs are useless paperwork
SLAs are often seen as imposing unnecessary constraints on teams already under pressure or as just another useless, overhyped, and unhelpful tool. If you define your SLA once as “Data is available at 7 am every day”, and then forget about it, that’s probably right. If the business tries to push unrealistic SLAs to you because they are tired of late-arriving data, that’s also not going to help. Data engineering is also heavily reliant on upstream systems it doesn’t control.
Not all data pipelines need SLAs
It’s difficult to abide by some SLAs when the issue is that a third-party vendor didn’t deliver a file on time. But that’s exactly where SLAs help. For example, acknowledging that you are dependent on a vendor forces you to set expectations, discuss the escalation path, and, if needed, outline financial penalties. You may think it does not apply to your team, and you may be right. Not all data pipelines need SLAs. A common mistake is trying to apply these rules to everything rather than focusing on the critical workloads. For example, in the airline industry, the load factor is a critical and highly visible KPI. It indicates how full the planes are and, therefore, how profitable each flight is. Business users review it daily to adjust day-to-day operations. The team I was working on had to ensure the data was refreshed and accurate every morning at 8 am. So we had to build a process to guarantee that, including understanding the end-to-end lineage and implementing monitoring, testing, on-call, and escalation paths. That’s a lot of work.
On the other hand, we didn’t have such a process for the marketing team when Facebook Ads data was late. The business team would still be able to do most of their work even if the data is three days late. Obviously, our objective was still to offer 24h freshness, but we allowed ourselves more flexibility in handling issues. The marketing team would still complain when the data is delayed, but with a 72-hour SLA, they could not make it sound worse than what it actually means for the business. Every data engineer had a moment with an angry stakeholder who escalated data issues to higher management. With SLAs, the discussion shifts from whether your team is doing a bad job to whether the SLA remains aligned with business needs.
SLAs are more than freshness indicators
SLAs create a contract between parties and make it visible. When people start using a dataset, they know what to expect and, therefore, establish trust in the data. As a data user, if the existing agreement is not acceptable for a use case, I know I have to either find another data source or discuss further with the engineering team, scope the effort, and get it prioritized. It is a healthy process. I remember a situation where a team had to report daily website logins to regulators. Their instinct was to use our Google Analytics (GA) dataset. They didn’t say anything and started using it. A few months later, this use case came up in a discussion, and that’s when we highlighted that we don’t guarantee 100% accuracy, as GA data can be inaccurate for various reasons, such as browsers blocking requests. This team didn’t expect that. It meant they had been sending inaccurate reports for months. For their defense, we didn’t have an SLA, nor good documentation. It wasn’t straightforward to determine that the dataset was incomplete. Such “misuse” of data happens frequently. SLAs are not just for data timeliness but also for completeness, schema stability, accuracy thresholds, or incident response time. When defined (even without calling it an SLA), others can know what to expect and decide whether to use the data.
Use SLAs to manage expectations
Do not systematically reject the idea of using SLAs in data. Don’t believe that they will force you to handle Airflow pipeline failures at 3 am. See them as a way to own your data and pipelines and to provide clarity for data users about what to expect. It is much easier to handle situations when expectations are clearly laid out beforehand than to deal with ambiguity and chaos when incidents occur. If expectations must change, it will definitely require more work from your engineers, but the business team can justify it, and the product team can prioritize it. And if you still don’t like the term “SLA”, apply the principles without naming it.
