diff --git a/website/content/en/docs/faq.md b/website/content/en/docs/faq.md
index 7d75585f0cff..ac276fa2c7f5 100644
--- a/website/content/en/docs/faq.md
+++ b/website/content/en/docs/faq.md
@@ -244,3 +244,11 @@ Details on provisioning the SQS queue and EventBridge rules can be found in the
 ### Why do I sometimes see an extra node get launched when updating a deployment that remains empty and is later removed?
 
 Consolidation packs pods tightly onto nodes which can leave little free allocatable CPU/memory on your nodes.  If a deployment uses a deployment strategy with a non-zero `maxSurge`, such as the default 25%, those surge pods may not have anywhere to run. In this case, Karpenter will launch a new node so that the surge pods can run and then remove it soon after if it's not needed.
+
+## Logging
+
+### How do I customize or configure the log output?
+
+Karpenter uses [uber-go/zap](https://github.com/uber-go/zap) for logging. You can customize or configure the log messages by editing the [configmap-logging.yaml](https://github.com/aws/karpenter/blob/main/charts/karpenter/templates/configmap-logging.yaml) 
+`ConfigMap`'s [data.zap-logger-config](https://github.com/aws/karpenter/blob/main/charts/karpenter/templates/configmap-logging.yaml#L26) field.
+The available configuration options are specified in the [zap.Config godocs](https://pkg.go.dev/go.uber.org/zap#Config).
\ No newline at end of file
diff --git a/website/content/en/preview/faq.md b/website/content/en/preview/faq.md
index 99532a02eb43..324639c49f9c 100644
--- a/website/content/en/preview/faq.md
+++ b/website/content/en/preview/faq.md
@@ -244,3 +244,11 @@ Details on provisioning the SQS queue and EventBridge rules can be found in the
 ### Why do I sometimes see an extra node get launched when updating a deployment that remains empty and is later removed?
 
 Consolidation packs pods tightly onto nodes which can leave little free allocatable CPU/memory on your nodes.  If a deployment uses a deployment strategy with a non-zero `maxSurge`, such as the default 25%, those surge pods may not have anywhere to run. In this case, Karpenter will launch a new node so that the surge pods can run and then remove it soon after if it's not needed.
+
+## Logging
+
+### How do I customize or configure the log output?
+
+Karpenter uses [uber-go/zap](https://github.com/uber-go/zap) for logging. You can customize or configure the log messages by editing the [configmap-logging.yaml](https://github.com/aws/karpenter/blob/main/charts/karpenter/templates/configmap-logging.yaml)
+`ConfigMap`'s [data.zap-logger-config](https://github.com/aws/karpenter/blob/main/charts/karpenter/templates/configmap-logging.yaml#L26) field.
+The available configuration options are specified in the [zap.Config godocs](https://pkg.go.dev/go.uber.org/zap#Config).
\ No newline at end of file
diff --git a/website/content/en/v0.26/faq.md b/website/content/en/v0.26/faq.md
index 02b6b4d9bcfc..fcf26b551a84 100644
--- a/website/content/en/v0.26/faq.md
+++ b/website/content/en/v0.26/faq.md
@@ -226,3 +226,11 @@ Details on provisioning the SQS queue and EventBridge rules can be found in the
 ### Why do I sometimes see an extra node get launched when updating a deployment that remains empty and is later removed?
 
 Consolidation packs pods tightly onto nodes which can leave little free allocatable CPU/memory on your nodes.  If a deployment uses a deployment strategy with a non-zero `maxSurge`, such as the default 25%, those surge pods may not have anywhere to run. In this case, Karpenter will launch a new node so that the surge pods can run and then remove it soon after if it's not needed.
+
+## Logging
+
+### How do I customize or configure the log output?
+
+Karpenter uses [uber-go/zap](https://github.com/uber-go/zap) for logging. You can customize or configure the log messages by editing the [configmap-logging.yaml](https://github.com/aws/karpenter/blob/main/charts/karpenter/templates/configmap-logging.yaml)
+`ConfigMap`'s [data.zap-logger-config](https://github.com/aws/karpenter/blob/main/charts/karpenter/templates/configmap-logging.yaml#L26) field.
+The available configuration options are specified in the [zap.Config godocs](https://pkg.go.dev/go.uber.org/zap#Config).
\ No newline at end of file
diff --git a/website/content/en/v0.27/faq.md b/website/content/en/v0.27/faq.md
index aea85d63cf48..cb52c565c539 100644
--- a/website/content/en/v0.27/faq.md
+++ b/website/content/en/v0.27/faq.md
@@ -225,3 +225,11 @@ Details on provisioning the SQS queue and EventBridge rules can be found in the
 ### Why do I sometimes see an extra node get launched when updating a deployment that remains empty and is later removed?
 
 Consolidation packs pods tightly onto nodes which can leave little free allocatable CPU/memory on your nodes.  If a deployment uses a deployment strategy with a non-zero `maxSurge`, such as the default 25%, those surge pods may not have anywhere to run. In this case, Karpenter will launch a new node so that the surge pods can run and then remove it soon after if it's not needed.
+
+## Logging
+
+### How do I customize or configure the log output?
+
+Karpenter uses [uber-go/zap](https://github.com/uber-go/zap) for logging. You can customize or configure the log messages by editing the [configmap-logging.yaml](https://github.com/aws/karpenter/blob/main/charts/karpenter/templates/configmap-logging.yaml)
+`ConfigMap`'s [data.zap-logger-config](https://github.com/aws/karpenter/blob/main/charts/karpenter/templates/configmap-logging.yaml#L26) field.
+The available configuration options are specified in the [zap.Config godocs](https://pkg.go.dev/go.uber.org/zap#Config).
\ No newline at end of file
diff --git a/website/content/en/v0.28/faq.md b/website/content/en/v0.28/faq.md
index 1d622502a066..3044d2115e56 100644
--- a/website/content/en/v0.28/faq.md
+++ b/website/content/en/v0.28/faq.md
@@ -230,3 +230,11 @@ Details on provisioning the SQS queue and EventBridge rules can be found in the
 ### Why do I sometimes see an extra node get launched when updating a deployment that remains empty and is later removed?
 
 Consolidation packs pods tightly onto nodes which can leave little free allocatable CPU/memory on your nodes.  If a deployment uses a deployment strategy with a non-zero `maxSurge`, such as the default 25%, those surge pods may not have anywhere to run. In this case, Karpenter will launch a new node so that the surge pods can run and then remove it soon after if it's not needed.
+
+## Logging
+
+### How do I customize or configure the log output?
+
+Karpenter uses [uber-go/zap](https://github.com/uber-go/zap) for logging. You can customize or configure the log messages by editing the [configmap-logging.yaml](https://github.com/aws/karpenter/blob/main/charts/karpenter/templates/configmap-logging.yaml)
+`ConfigMap`'s [data.zap-logger-config](https://github.com/aws/karpenter/blob/main/charts/karpenter/templates/configmap-logging.yaml#L26) field.
+The available configuration options are specified in the [zap.Config godocs](https://pkg.go.dev/go.uber.org/zap#Config).
\ No newline at end of file
diff --git a/website/content/en/v0.29/faq.md b/website/content/en/v0.29/faq.md
index 7d75585f0cff..e502823271b3 100644
--- a/website/content/en/v0.29/faq.md
+++ b/website/content/en/v0.29/faq.md
@@ -244,3 +244,11 @@ Details on provisioning the SQS queue and EventBridge rules can be found in the
 ### Why do I sometimes see an extra node get launched when updating a deployment that remains empty and is later removed?
 
 Consolidation packs pods tightly onto nodes which can leave little free allocatable CPU/memory on your nodes.  If a deployment uses a deployment strategy with a non-zero `maxSurge`, such as the default 25%, those surge pods may not have anywhere to run. In this case, Karpenter will launch a new node so that the surge pods can run and then remove it soon after if it's not needed.
+
+## Logging
+
+### How do I customize or configure the log output?
+
+Karpenter uses [uber-go/zap](https://github.com/uber-go/zap) for logging. You can customize or configure the log messages by editing the [configmap-logging.yaml](https://github.com/aws/karpenter/blob/main/charts/karpenter/templates/configmap-logging.yaml)
+`ConfigMap`'s [data.zap-logger-config](https://github.com/aws/karpenter/blob/main/charts/karpenter/templates/configmap-logging.yaml#L26) field.
+The available configuration options are specified in the [zap.Config godocs](https://pkg.go.dev/go.uber.org/zap#Config).
\ No newline at end of file