diff --git a/sig-scalability/slos/api_call_latency.md b/sig-scalability/slos/api_call_latency.md
index 7e6b07854..45764f9c5 100644
--- a/sig-scalability/slos/api_call_latency.md
+++ b/sig-scalability/slos/api_call_latency.md
@@ -27,15 +27,15 @@ namespaces.
 - As a user of vanilla Kubernetes, I want some guarantee how quickly I get the
 response from an API call.
 - As an administrator of Kubernetes cluster, if I know characteristics of my
-external dependencies of apiserver (e.g custom admission plugins, webhooks and
-initializers) I want to be able to provide guarantees for API calls latency to
-users of my cluster.
+external dependencies of apiserver (e.g custom admission plugins and webhooks)
+I want to be able to provide guarantees for API calls latency to users of my
+cluster.
 
 ### Other notes
 - We obviously can’t give any guarantee in general, because cluster
-administrators are allowed to register custom admission plugins, webhooks
-and/or initializers, which we don’t have any control about and they obviously
-impact API call latencies.
+administrators are allowed to register custom admission plugins or webhooks,
+which we don’t have any control about and they obviously impact API call
+latencies.
 - As a result, we define the SLIs to be very generic (no matter how your
 cluster is set up), but we provide SLO only for default installations (where we
 have control over what apiserver is doing). This doesn’t provide a false
diff --git a/sig-scalability/slos/api_extensions_latency.md b/sig-scalability/slos/api_extensions_latency.md
index c5490ec19..5c8013049 100644
--- a/sig-scalability/slos/api_extensions_latency.md
+++ b/sig-scalability/slos/api_extensions_latency.md
@@ -6,9 +6,8 @@
 | --- | --- |
 | WIP | Admission latency for each admission plugin type, measured as 99th percentile over last 5 minutes |
 | WIP | Webhook call latency for each webhook type, measured as 99th percentile over last 5 minutes
-| WIP | Initializer latency for each initializer, measured as 99th percentile over last 5 minutes |
 
 ### User stories
 - As an administrator, if API calls are slow, I would like to know if this is
-because slow extension points (admission plugins, webhooks, initializers) and
-if so which ones are responsible for it.
+because slow extension points (admission plugins, webhooks) and if so which ones
+are responsible for it.
diff --git a/sig-scalability/slos/slos.md b/sig-scalability/slos/slos.md
index fe3bda434..0cdb576b8 100644
--- a/sig-scalability/slos/slos.md
+++ b/sig-scalability/slos/slos.md
@@ -135,5 +135,4 @@ sliding window. However, for the purpose of SLO itself, it basically means
 | WIP | Watch latency for every resource, (from the moment when object is stored in database to when it's ready to be sent to all watchers), measured as 99th percentile over last 5 minutes | [Details](./watch_latency.md) |
 | WIP | Admission latency for each admission plugin type, measured as 99th percentile over last 5 minutes | [Details](./api_extensions_latency.md) |
 | WIP | Webhook call latency for each webhook type, measured as 99th percentile over last 5 minutes | [Details](./api_extensions_latency.md) |
-| WIP | Initializer latency for each initializer, measured as 99th percentile over last 5 minutes | [Details](./api_extensions_latency.md) |