{"id":2655,"date":"2026-03-11T09:30:00","date_gmt":"2026-03-11T09:30:00","guid":{"rendered":"https:\/\/mugnos-it.com\/?p=2655"},"modified":"2026-03-03T12:58:54","modified_gmt":"2026-03-03T12:58:54","slug":"what-is-the-importance-of-defining-good-slis-slos-and-slas","status":"publish","type":"post","link":"https:\/\/mugnos-it.com\/pt\/what-is-the-importance-of-defining-good-slis-slos-and-slas\/","title":{"rendered":"What is the importance of defining good SLIs, SLOs, and SLAs?"},"content":{"rendered":"
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\n

\u201cCan you take a look at the service for me?\u201d<\/p>\n\n\n\n

If you\u2019ve ever heard that in the middle of a sprint, incident, or code review\u2026 you know how frustrating that sentence can be.<\/p>\n\n\n\n

Check what? Based on what? Just because the API returned 200<\/code> and the front-end buttons rendered, does that really mean everything is healthy?<\/p>\n\n\n\n

We need to stop guessing. And start defining what a healthy system actually means<\/strong>.<\/p>\n\n\n\n

That\u2019s where the famous (and often ignored) concepts come in:<\/p>\n\n\n\n

\n

SLI, SLO and SLA<\/p>\n<\/blockquote>\n\n\n\n

\n\n\n\n

What are SLI, SLO and SLA? (With real examples)<\/h2>\n\n\n\n

SLI \u2013 Service Level Indicator<\/strong><\/h3>\n\n\n\n

It\u2019s the raw metric<\/strong> you\u2019re observing. Example:<\/p>\n\n\n\n

SLI Name<\/th>What it measures<\/th>Practical example<\/th><\/tr><\/thead>
Error rate<\/td>% of HTTP requests returning errors<\/td>Requests to \/checkout<\/code> with 5xx status<\/td><\/tr>
Availability<\/td>% of time an endpoint is accessible<\/td>Availability of \/api\/auth\/login<\/code><\/td><\/tr>
Latency<\/td>Response time of requests<\/td>Time to receive response from \/payment\/process<\/code><\/td><\/tr>
Throughput<\/td>Volume of processed requests<\/td>Number of requests\/sec on \/orders\/list<\/code><\/td><\/tr>
Saturation<\/td>Usage of critical system resources<\/td>Kafka order queue above 80% occupancy<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n

SLO \u2013 Service Level Objective<\/strong><\/h3>\n\n\n\n

It\u2019s the internal technical agreement<\/strong> about the minimum acceptable value for that SLI. Example:<\/p>\n\n\n\n

SLI<\/th>Suggested SLO<\/th><\/tr><\/thead>
Error rate of \/checkout<\/code><\/td>Less than 0.1% 5xx errors over 30 days<\/td><\/tr>
Availability of \/auth\/login<\/code><\/td>99.95% monthly uptime<\/td><\/tr>
Latency on \/payment\/process<\/code><\/td>95% of responses under 300ms<\/td><\/tr>
Throughput on \/orders\/list<\/code><\/td>At least 100 sustained RPS without errors<\/td><\/tr>
Kafka payment queue saturation<\/td>Queue must never exceed 80% for more than 5 consecutive minutes<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n

SLA \u2013 Service Level Agreement<\/strong><\/h3>\n\n\n\n

It\u2019s the formal agreement with a client or business team<\/strong>. Example:<\/p>\n\n\n\n

\n

\u201cIf monthly availability of \/auth\/login drops below 99.5%, there will be a contractual penalty of X dollars.\u201d<\/p>\n<\/blockquote>\n\n\n\n

We won\u2019t go deep into SLAs here, because the focus is helping you build real visibility and strong technical agreements within your team using SLI + SLO.<\/p>\n\n\n\n

\n\n\n\n

A Practical Example (With Template)<\/h2>\n\n\n\n

Imagine you have a payment API<\/strong> running in containers on Kubernetes. Below is a table with real SLI\/SLO examples you can use as a base to implement observability + alerts<\/strong>.<\/p>\n\n\n\n

Metric (SLI)<\/th>Objective (SLO)<\/th>Where to measure<\/th>Alert Type<\/th>Priority<\/th><\/tr><\/thead>
HTTP 5xx error rate on \/payment\/checkout<\/code><\/td>< 0.1% over last 7 days<\/td>API Gateway \/ APM (Datadog, Prometheus, etc.)<\/td>Alert if > 0.1% for 15 min<\/td>High<\/td><\/tr>
Latency on \/payment\/process<\/code><\/td>95% < 300ms (p95)<\/td>Distributed tracing + Logs<\/td>Alert if p95 > 300ms for 5 min<\/td>High<\/td><\/tr>
Availability of payment-api<\/code> container<\/td>99.95% monthly<\/td>Kubernetes healthcheck + Prometheus<\/td>Alert if container crashing\/restarting<\/td>High<\/td><\/tr>
CPU usage of container<\/td>< 70% sustained<\/td>Prometheus \/ Grafana<\/td>Alert if > 70% for 10 min<\/td>Medium<\/td><\/tr>
Memory usage of container<\/td>< 75% sustained<\/td>Prometheus \/ Grafana<\/td>Alert if > 75% for 10 min<\/td>Medium<\/td><\/tr>
Kafka payment queue usage<\/td>< 80% buffer<\/td>Kafka Exporter + Prometheus<\/td>Alert if > 80% for 10 min<\/td>High<\/td><\/tr>
Kafka backlog<\/td>< 1,000 delayed messages<\/td>Kafka metrics<\/td>Alert if backlog grows for 10 min<\/td>High<\/td><\/tr>
Database availability<\/td>> 99.9% weekly<\/td>DB Proxy or APM monitoring<\/td>Alert if unavailable for > 1 min<\/td>High<\/td><\/tr>
Auth request error rate (\/auth<\/code>)<\/td>< 0.2% over 7 days<\/td>API Gateway or Auth Service<\/td>Alert if spike > 0.2% for 15 min<\/td>High<\/td><\/tr>
Total service throughput<\/td>Sustain > 100 RPS stably<\/td>APM + Load Balancer metrics<\/td>Alert if abrupt drop in throughput<\/td>High<\/td><\/tr>
Internal job queue time (e.g., invoice generation)<\/td>< 1s average<\/td>Job runner metrics or Prometheus<\/td>Alert if average > 1s for 5 min<\/td>Medium<\/td><\/tr>
p99 latency on \/refunds<\/code><\/td>< 500ms<\/td>APM or tracing<\/td>Alert if p99 > 500ms for 10 min<\/td>Medium<\/td><\/tr>
External call errors (e.g., payment gateway)<\/td>< 0.5%<\/td>Circuit breaker + logs<\/td>Alert on spike or constant timeout<\/td>High<\/td><\/tr>
Automatic retry rate<\/td>< 2% of requests<\/td>Retry middleware<\/td>Alert if > 2% for 15 min<\/td>Low<\/td><\/tr>
Event deserialization\/parse errors<\/td>0 invalid events<\/td>Kafka consumer + logs<\/td>Alert if invalid event received<\/td>High<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n

Now it\u2019s on you:<\/h2>\n\n\n\n

The table above is just an example<\/strong>. Every system has its own characteristics, critical points, and specific needs.<\/p>\n\n\n\n

What you can (and should) do now:<\/strong><\/p>\n\n\n\n

    \n
  1. Pick one microservice from your system<\/li>\n\n\n\n
  2. List its main endpoints and responsibilities<\/li>\n\n\n\n
  3. Define 5 to 10 real SLIs<\/strong> that represent what \u201chealth\u201d means there<\/li>\n\n\n\n
  4. For each SLI, define an SLO<\/strong><\/li>\n\n\n\n
  5. Configure monitoring and alerts based on those SLOs<\/strong><\/li>\n\n\n\n
  6. Share it with the team (it\u2019s useless if only you know it)<\/li>\n<\/ol>\n\n\n\n
    \n\n\n\n

    To wrap up: what if this became culture?<\/h2>\n\n\n\n

    Now imagine this\u2026<\/p>\n\n\n\n

    You have all your SLIs clearly defined<\/strong>, your SLOs visible on a dashboard<\/strong>, alerts configured with clear criteria \u2014 and the whole team knowing exactly what a healthy system looks like<\/strong>.<\/p>\n\n\n\n

    It would be much easier to make decisions, right?<\/p>\n\n\n\n

      \n
    • Knowing when it\u2019s time to act (and when it\u2019s not)<\/li>\n\n\n\n
    • Having clarity about system health without relying on assumptions<\/li>\n\n\n\n
    • Avoiding repetitive and meaningless work (the famous toil work<\/em> from SRE principles)<\/li>\n\n\n\n
    • Focusing on what really matters: delivering value with stability<\/li>\n<\/ul>\n\n\n\n

      SLO is not meant to become a forgotten spreadsheet.<\/strong> It\u2019s meant to be used every single day<\/strong> as the compass for reliability.<\/p>\n\n\n\n

      \n\n\n\n

      Want to learn MORE?<\/h2>\n\n\n\n

      honestly? I don\u2019t think you should be doing all of this manually anymore.<\/p>\n\n\n\n

      I\u2019m about to launch a new training called \u201cSRE Efficient: How AI Transforms Reliability Engineering\u201d<\/strong>, and in one of the classes I show exactly how you can use LLMs to help you define SLIs, SLOs \u2014 and even generate incident summaries in minutes.<\/p>\n\n\n\n

      Yes. Minutes.<\/p>\n\n\n\n

      If you want to see how AI can amplify your reliability practice instead of just generating alerts and dashboards, stay tuned.<\/p>\n\n\n\n

      More details coming very soon. \ud83d\ude80<\/p>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

      \n\t\t\t\t\t
      \n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>","protected":false},"excerpt":{"rendered":"

      \u201cCan you take a look at the service for me?\u201d If you\u2019ve ever heard that in the middle of a sprint, incident, or code review\u2026 you know how frustrating that sentence can be. Check what? Based on what? Just because the API returned 200 and the front-end buttons rendered, does that really mean everything is […]<\/p>","protected":false},"author":3,"featured_media":2656,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2655","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/mugnos-it.com\/wp-content\/uploads\/2026\/03\/Vem-conferir-minha-pagina-de-treinamentos-2.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/2655","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/comments?post=2655"}],"version-history":[{"count":4,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/2655\/revisions"}],"predecessor-version":[{"id":2660,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/posts\/2655\/revisions\/2660"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/media\/2656"}],"wp:attachment":[{"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/media?parent=2655"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/categories?post=2655"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mugnos-it.com\/pt\/wp-json\/wp\/v2\/tags?post=2655"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}