221 stars · Apache-2.0, named in the About sidebar · v0.13.0, read from /releases/latest as 'June 29' with no year, which falls in the past and is therefore 2026 · Track this in Scout
A command-line checker and formatter for files that state service level objectives.
Radar check
What we found when we opened it. Every bar is one fact, with its date.
Last code pushed 7 Apr 2026, 6 months before this check.
Latest release v0.13.0 on 29 Jun 2025.
Public since April 2021, a little over 5 years.
222 stars and 37 forks.
0 commits and 0 new issues in the last 90 days.
23 contributors. No pull requests merged in 90 days; changes go in directly.
No security policy file says how to report a problem. No published security advisories.
How the bars are scored
- Alive. Days since the last code push: a week or less 100, a month 90, three months 70, six months 50, a year 30, eighteen months 15, older 0.
- Releases. Age of the latest GitHub release, on a similar scale; no bar when the project publishes no releases.
- Maturity. Age of the project: eight years 100, five 90, three 70, two 55, one 40, six months 25, younger 10.
- Adoption. Stars on a log scale: 100,000 stars is 100, 10,000 is 80, 1,000 is 60, 100 is 40.
- Activity. Commits in the last 90 days: 300 or more 100, 100 85, 30 65, 10 45, any 25.
- Community. People who have contributed: 100 or more 100, 30 80, 10 60, 5 40, 2 25, one 10.
- Security. A published security policy 80, none 40; published advisories are listed, not scored.
Checked by Repo Radar on 27 Oct 2026 from the repository on GitHub. Covered in Edition 63.
▶Repo detailsthe review · specs · pros & cons · install
What it does
It reads files written in the OpenSLO format, which is a vendor-neutral way of writing down a service promise so that different monitoring products can read the same file. oslo validate checks one or more files and reports what is wrong. oslo fmt rewrites them in the standard layout, so that files written by different people look the same. It accepts several files in one command. It ships as a single compiled program with no dependencies, with 458 commits and 221 stars. Version 0.13.0 was published on 29 June 2026. It does not collect measurements, does not calculate whether a promise was kept, does not alert, and does not talk to any monitoring system: it reads a file and tells you whether that file is correct.
Why it matters
Who it suits. A small team that has started writing its reliability promises into files and keeping them beside the code, and that wants a check in the build so a malformed promise never reaches production. It also suits anyone comparing monitoring products, because writing the promises in a neutral format first means they do not have to be rewritten when the product changes. Skip it if no promises are written down yet, because the useful work is deciding what to promise, and a formatter cannot help with that.
Verdict. This is a narrow tool and it should be judged narrowly. As a step in a build it is exactly right: fast, single-purpose, and it fails loudly on a bad file. What it is not is a reason to adopt the format. The format earns its place only if two or more monitoring products in use can read it, and most teams have one. The 221 stars are a fair reflection of how few people need this, not of quality. Anyone who actually wants promises measured and alerted on should go to slok/sloth, which turns a written promise into working alert rules, or pyrra-dev/pyrra, which adds a screen showing how much of the allowance is left. This checks the paperwork; those two do the work.
- One compiled program, no dependencies, installable in a line and easy to put in a build.
- Formatting as well as checking, so files written by different hands end up identical.
- A neutral file format, so the promises survive a change of monitoring product.
- It measures nothing and alerts on nothing. It only reads files.
- Useful only to teams who have already adopted this particular format.
- 221 stars and a quiet pace, so expect little help if something is unclear.
slok/slothTurns a written promise into working alert rules; the tool that does the measuring this one leaves alone.
Track this in Scout
pyrra-dev/pyrraManages promises and shows how much of the error allowance is left; adds a screen, and is tied to one monitoring system.
Track this in Scout
go install github.com/OpenSLO/oslo/cmd/oslo@latest
