Keptn v1 reached EOL December 22, 2023. For more information see


The sli.yaml file contains definitions of the Service-Level Indicators (SLIs) defined for your Keptn installation. The SLI definition maps a query provided for the observability platform you are using as a data source to a metric value that Keptn uses.

Each SLI is a defined quantitative measure of some aspects of the service level. The query for an SLI is provider/tool-dependent; therefore, each SLI-provider relies on a specific SLI configuration.

Provider-specific SLIs are discussed in the documentation for the integrations of each monitoring platform:

You can also create and add your custom SLI-provider to Keptn. Follow the instructions Custom SLI-Provider.

Service-Level Indicator format

The SLI configuration contains a list of indicators, each of which always consists of a name and the provider-specific query.

  • Each SLI is a key-value pair
    • The SLI name or metric is the key
    • The provider-specific query is the value.
  • The sli.yaml file can contain any number of SLIs.

Add SLI configuration to a Service, Stage, or Project

You must add the SLI the Keptn service for your monitoring platform to your service, stage, or project.

Important: In the following commands, the value of the resourceUri must specify the SLI-provider that can fetch the declared SLIs. For Dynatrace, the value of the resourceUri must be: dynatrace/sli.yaml.

  • To add an SLI configuration to a service, use the keptn add-resource command:

    keptn add-resource --project=sockshop --stage=staging --service=carts --resource=sli-config.yaml  --resourceUri=dynatrace/sli.yaml
  • To add an SLI configuration to a stage, use the keptn add-resource command:

    keptn add-resource --project=sockshop --stage=staging --resource=sli-config.yaml --resourceUri=dynatrace/sli.yaml

    Note: This SLI configuration is applied for all services in this stage.

  • To add an SLI configuration to a project, use the keptn add-resource command:

    keptn add-resource --project=sockshop --resource=sli-config.yaml --resourceUri=dynatrace/sli.yaml

    Note: This SLI configuration is applied for all services in all stages of this project.

Example of multiple SLI configurations:

  • Let’s assume we add the following SLI configurations to a project, stage, and service:

    • SLI configuration on project-level:
    spec_version: "1.0"
      throughput: "query A-1"
      error_rate: "query B-1"
      response_time_p95: "query C-1"
    • SLI configuration on stage-level:
    spec_version: "1.0"
      response_time_p95: "query C-2"
      response_time_p99: "query D-2"
    • SLI configuration on service-level:
    spec_version: "1.0"
      response_time_p99: "query D-3"
      sql-statements: "query E-3"
  • If an evaluation of a service gets triggered, the following SLI configuration is used:

    spec_version: "1.0"
      throughput: "query A-1"         # SLI from project level
      error_rate: "query B-1"         # SLI from project-level
      response_time_p95: "query C-2"  # SLI from stage-level overrides SLI from project-level
      response_time_p99: "query D-3"  # SLI from service-level overrides SLI from stage-level
      sql-statements: "query E-3"     # SLI from service-level

Using different SLI environments

Different projects, stages, and services within stages can utilize different environments for your SLI. To do this, you create different configuration files for your SLI and have each point to a unique secret that contains the API endpoint for your SLI and a token.

The implementation specifics are different for each SLI provider. As an example, we explain how to do this when using Dynatrace. Consult the documentation for your SLI for the specifics.

Each SLI has a configuration file; for Dynatrace, it is dynatrace.conf.yaml. You can create multiple versions of this file to use different environments for different projects, stages, and services by locating a version of the file in the appropriate directory in your upstream Git repo. For example, if your project has the dev, qa and prod stages, you could create a unique dynatrace.conf.yaml file in each of these directories on Git. Within each file, modify the value for the API credentials secret name; for Dynatrace, this is the dtCreds field.

The service first looks for a configuration on the service level, then at the stage level, and finally at the project level if no other configurations are found.

See also