# slo-generator turns backend metrics into SLO, error budget and burn rate reports > slo-generator is a Google tool that runs backend queries to compute Service Level Indicators, compares them against Service Level Objectives defined in YAML or JSON, and exports a report with error budgets and burn rates. It is Apache-2.0 licensed, installable from PyPI with per-provider extras, and usable as a CLI or as a Flask API on Cloud Run, Kubernetes or Cloud Functions. **google/slo-generator** — SLO Generator computes SLIs, SLOs, Error Budgets and Burn Rates from supported backends, then exports an SLO report to supported targets. - Repository: https://github.com/google/slo-generator - Stars: 564 · Forks: 90 - Language: Python - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/google-slo-generator ## The three metrics the tool exists to compute The slo-generator is a tool to compute and export Service Level Objectives, Error Budgets and Burn Rates, using configurations written in YAML, or JSON, format. Underneath, it does one thing and derives the rest from it. It runs backend queries computing Service Level Indicators, compares them with the Service Level Objectives defined, and generates a report by computing important metrics. The metrics are defined precisely, which is worth reading because the definitions are what makes the output comparable across teams. The Service Level Indicator is defined as SLI = N_good_events divided by N_valid_events. The Error Budget is defined as EB = 1 - SLI. And the Error Budget Burn Rate is defined as EBBR = EB divided by EB_target. The burn rate is the number that makes the tool worth having in a paging workflow. The README states that it is often used for alerting on SLOs, as it demonstrates in practice to be more reliable and stable than alerting directly on metrics or on SLI greater than SLO thresholds. That claim is the substance of the alerting-on-SLOs approach, and the tool implements it as arithmetic rather than asking you to. A burn rate of 2 means you are consuming the error budget twice as fast as sustainable, and alerting on a burn rate rather than on a raw threshold is what stops a service from paging you for a budget it can absorb. The report format itself is documented by example, in an example SLO report fixture under the tests directory, and the README links it as showing more than the three metrics above. The primary language is Python, the licence is Apache-2.0, and the last push to the repository was on 2026-08-12. ## Installing it and choosing the extras The tool is a Python library published on PyPI, and the install is one command: ```sh pip3 install slo-generator ``` The requirements are python3.8 and above, plus pip3. The extras are the part that matters, because the backends are optional dependencies. To install providers, use pip3 install slo-generator[, , ... ], and the README gives two concrete examples: pip3 install slo-generator[cloud_monitoring] installs the Cloud Monitoring backend and exporter, and pip3 install slo-generator[prometheus, datadog, dynatrace] installs those three backends and exporters. So the base install gives you the core and you add the backends you actually query. That is a sensible arrangement for a tool whose dependency list would otherwise include a client library for every monitoring system in existence. Two more extras exist. To install the slo-generator API, run pip3 install slo-generator[api]. Two environment variables affect the local experience. To enable debug logs, set the environment variable DEBUG to 1. To enable colorized output for local usage, set COLORED_OUTPUT to 1. The Dockerfile in the repository shows what a complete install looks like, and it lists the full set of extras the production image carries: api, bigquery, cloud_monitoring, cloud_service_monitoring, cloud_storage, cloudevent, datadog, dynatrace, elasticsearch, opensearch, prometheus, pubsub and splunk. The image is built on python:3.11-alpine by default, with the Python version defined as a build argument that has to be propagated to a repository variable in GitHub settings, and the entrypoint is the slo-generator command itself. The samples directory matches that list with a directory per provider: cloud_monitoring, cloud_monitoring_mql, cloud_service_monitoring, custom, datadog, dynatrace, elasticsearch, opensearch, prometheus, splunk and test, plus config.yaml, config_export.yaml and a .env.sample. ## The two commands: compute and api There are two entry points and they take different arguments. For the CLI, the command to compute an SLO report is: ```sh slo-generator compute -f -c --export ``` The SLO_CONFIG_PATH is the SLO configuration file or folder path, so the tool can take a directory of SLO definitions rather than a single file. The SHARED_CONFIG_PATH is the shared configuration file path. The --export, or -e, flag enables exporting data using the exporters specified in the SLO configuration file, which is how the report reaches BigQuery or another target. Use slo-generator compute --help to list all available arguments. The API is the second mode. On top of the CLI, the slo-generator can also be run as an API using the Cloud Functions Framework SDK, which is Flask, using the api subcommand: ```sh slo-generator api --config ``` The shared configuration path can be a file path or a GCS URL there, which is what makes the API deployable as a Cloud Run service with its configuration in a bucket. Once the API is up and running, you make HTTP POST requests with your SLO configurations, YAML or JSON, in the request body: ```sh curl -X POST -H "Content-Type: text/x-yaml" --data-binary @slo.yaml localhost:8080 # yaml SLO config curl -X POST -H "Content-Type: application/json" -d @slo.json localhost:8080 # json SLO config ``` The content type does the work of deciding which parser to use, so the same service handles both formats. The port in the example is 8080, which is the port a Cloud Run container expects, and the Dockerfile's default command is -v for the version, so the image is usable for both. The API mode is the one that changes the operational model. The CLI is a batch job you run on a schedule, while the API is a service you deploy and call, which is what the Cloud Run, Kubernetes, CloudBuild and Cloud Functions sections of the documentation are about. ## The configuration format and where it comes from The tool requires two configuration files to run: an SLO configuration file describing your SLO, and the Shared configuration file, which is the common configuration for all SLOs. The SLO configuration, in JSON or YAML, follows the Kubernetes format, and the fields are worth knowing precisely because the requirements are stated as constraints rather than suggestions. The api field is sre.google.com/v2 and the kind is ServiceLevelObjective. Under metadata, the name is a required string and the full SLO name, which must be unique, and the labels are an optional map with examples given: slo_name for the SLO name such as availability or latency128ms, service_name for the monitored service to group SLOs by service, and feature_name for the monitored feature. Under spec, the description is a required string. The goal is a required string holding the SLO goal or target, which must be between 0 and 1. The backend is required and must exist in the SLO Generator configuration. The method is required and must exist in the backend class definition. The service_level_indicator is a required map, and its contents are specific to each provider, with the provider documentation linked for the details. The error_budget_policy is optional, must exist in the configuration if given, and defaults to default. The exporters are optional and must exist in the configuration if given. That format is a deliberate choice. A Kubernetes-shaped manifest means the SLO definitions live in the same repository and the same review flow as the rest of your configuration, and it means an SLO file can be linted and validated the same way a deployment manifest is. One detail has operational value. You can use environment variables in your SLO configs by using the ${MY_ENV_VAR} syntax to avoid having sensitive data in version control, and the variables are replaced automatically at run time. For a team that keeps SLO definitions in git, that is what makes the pattern workable at all when a query needs a credential. The other side of the configuration is the shared file, which holds the backends, the exporter settings and the error budget policies that the SLO files reference by name. ## Deployment targets and the repository tooling The documentation covers five deployment shapes, and the list tells you what the tool is expected to run on. There is a section on building an SLO achievements report with BigQuery and DataStudio, a section on deploying in Cloud Run, a section on deploying in Kubernetes marked Alpha, a section on deploying in a CloudBuild pipeline, and a section marked DEPRECATED for deploying on Google Cloud Functions with Terraform. That last marker is worth noting. Cloud Functions is deprecated in favour of Cloud Run, and the tool's documentation has been updated to say so while keeping the old instructions for existing deployments. A v1 documentation set also exists on a v1.5.1 tag, and there is a migration guide at docs/shared/migration.md, with the README stating plainly that the content it shows is the v2 documentation. The repository is set up for a Google release process. There is a cloudbuild.yaml at the root, a Dockerfile, a Makefile whose targets include build, deploy with twine, install, test, unit, coverage, lint and audit, and an integration target for integration tests. The test target runs install, unit, lint and audit in sequence, and the audit target is described as a CVE scan. The Python packaging uses pyproject.toml with setuptools and wheel as the build requirements and the setuptools.build_meta backend, plus a setup.py that does nothing but call setup(). The setup.cfg carries the version, and the Makefile reads it with grep. The linting is ruff with a rule selection covering pycodestyle, Pyflakes, pyupgrade, flake8-bugbear, flake8-simplify, isort and Pylint, and mypy is configured to ignore missing imports, with pytype configured to look at the slo_generator package. The release history is the one thing that looks quiet. The listed releases are v2.6.0 from 2024-02-19, v2.5.2 from 2023-11-10 and v2.5.1 from 2023-10-13, so the last tagged release is more than two years old, while the last push was on 2026-08-12. There is a CHANGELOG.md at the root and the README carries badges for the test, build and deploy workflows and for the PyPI version. ## Where slo-generator fits, and where it stops The comparison worth making is with building the queries and the alerting rules yourself, and with the monitoring tools' own SLO features. Against doing it by hand, the difference is that the arithmetic and the report shape are the same everywhere. A team with five services otherwise writes five different PromQL or MQL queries, five different thresholds and five different dashboards, and the burn rate maths, which is where the mistakes happen, gets redone each time. Here the objective is a field in a manifest, the query is a provider-specific block, and the burn rate comes out of the tool. Against a monitoring vendor's built-in SLO feature, the difference is backend breadth and where the report goes. Cloud Monitoring has its own SLO objects and Datadog has its own monitors, and either is a reasonable choice if you are standardised on one. The argument for slo-generator is that the SLO definitions follow the Kubernetes format, the provider extras are numerous, and the export targets are separate from the query backends, so you can query one system and report into another. The limits are worth stating plainly. The tool does not tell you what your objectives should be. The goal is required and must be between 0 and 1, the backend and method must exist, and the service_level_indicator contents are specific to each provider, so a meaningful configuration is a piece of work per SLO that the tool cannot do for you. The Kubernetes deployment path is marked Alpha and the Cloud Functions path is deprecated, which narrows the supported production shapes. There is also the release cadence. The last tag is v2.6.0 from February 2024 with pushes continuing into August 2026, which is the profile of a project that is maintained but not cut frequently, and a team that wants a supported tool with a predictable release train would need to judge that for themselves. And the API mode has a security shape worth thinking about. The service accepts SLO configurations in the request body and runs backend queries, so whoever can reach it can drive queries against your monitoring backends. The README does not document authentication for the API, so that is something to settle before exposing it beyond a trusted network. ## Conclusion slo-generator suits a team that has already decided to run on SLOs and wants the measurement and the burn rate alerting maths computed consistently rather than assembled in a dashboard, since the tool covers the query, the comparison against the objective and the export in one pipeline and supports a wide set of backends through extras. It is the wrong tool if you are deciding what your objectives should be, since the configuration requires you to supply the goal, the backend and the method, and it is the wrong tool if you need a hosted service, since there is no product here, only a command and a library. Before you start, read docs/providers for the service_level_indicator block of your backend, and note that the current release line is v2 while v1 documentation and a migration guide both exist. ## FAQ ### What does slo-generator compute? It runs backend queries to compute Service Level Indicators, compares them with the Service Level Objectives defined in configuration, and generates a report with error budgets and burn rates. The Service Level Indicator is defined as good events divided by valid events, the Error Budget as 1 minus the SLI, and the Error Budget Burn Rate as the Error Budget divided by the target. ### How do I install slo-generator and a specific backend? Run pip3 install slo-generator for the core, then add providers with extras, for example pip3 install slo-generator[cloud_monitoring] or pip3 install slo-generator[prometheus, datadog, dynatrace]. The API is a separate extra installed with pip3 install slo-generator[api], and the project requires python3.8 and above. ### What is the SLO configuration format? The SLO configuration is JSON or YAML following the Kubernetes format, with api sre.google.com/v2 and kind ServiceLevelObjective. It requires metadata.name, spec.description, spec.goal between 0 and 1, spec.backend, spec.method and spec.service_level_indicator, with spec.error_budget_policy and spec.exporters optional. The service_level_indicator contents are specific to each provider. ### How do I run slo-generator as an API? Run slo-generator api --config , where the shared config can be a file path or a GCS URL. The API uses the Cloud Functions Framework SDK, Flask, and accepts HTTP POST requests with the SLO configuration in the body, as text/x-yaml or application/json. The example calls it on localhost:8080. ### Can I keep secrets out of my SLO configuration files? Yes. You can use environment variables in your SLO configs with the ${MY_ENV_VAR} syntax to avoid having sensitive data in version control, and the variables are replaced automatically at run time. ### What deployment options are documented for slo-generator? Building an SLO achievements report with BigQuery and DataStudio, deploying to Cloud Run, deploying to Kubernetes, which is marked Alpha, deploying in a CloudBuild pipeline, and a Google Cloud Functions deployment with Terraform, which is marked DEPRECATED. The README also notes that v1 documentation exists on the v1.5.1 tag and that migration instructions to v2 are provided. ## Sources - [google/slo-generator on GitHub](https://github.com/google/slo-generator) - [Issues](https://github.com/google/slo-generator/issues) - [License: Apache-2.0](https://github.com/google/slo-generator/blob/master/LICENSE) - [README](https://github.com/google/slo-generator/blob/master/README.md) - [Releases](https://github.com/google/slo-generator/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-slo-generator