Document planned use cases

[steventhurgood]

What are the expected consumers for these SLO definitions? There should be a section in the introduction which gives a few examples, to give people a better understanding of why they would use this.

For example:

• Auto-generating documentation
• Auto-generating alerts and reports
• Providing an agenda for SLO review meetings
• etc.

[iredelmeier]

Agreed. I'm very interested to learn what the larger roadmap is.

As an end user, the spec alone feels like it provides sugar but doesn't yet solve my larger problems - and I imagine that everyone involved has many ideas on their mind!

[gplasky]

I would add something even more fundamental: To ensure that we* articulate SLOs in a consistent, understandable, and consumable format. Auto-generated dashboards / docs / etc. are second-order outcomes (but nevertheless still important :) ).

*we = companies / SREs / the broader community

[pushpdeep]

Hi @ian-bartholomew I am thinking to add a use case.

[bobo]

I'm aware this is a very old issue but still feels relevant. I want to add some more things that would be interesting to see if they are in/outside scope.

• Non slo/sli alerts, not every alert is based on an slo.
• Non slo/sli metrics, for example to generate dashboards.

Im myself very sceptical to if theese should be in scope. But i would also hate to have separate definitions of the "same" thing just because they are not slo/sli based. I dont want to add metrics to monitor some non slo value in one way, and another way to monitor my slo values.
But also, having openslo support creating non slo dashboards sounds weird.
Maybe someone has already given lots of thought into this? I think stating what's not in scope is just as important as what is in scope sometimes.

[fourstepper]

@bobo my thoughts on this are currently to let these be defined by other specifications, for example PrometheusRule from the prometheus-operator project for alerts that aren't based on an SLO