diff --git a/monitoring/values-kube-prometheus-stack.yaml b/monitoring/values-kube-prometheus-stack.yaml
index 66b9ec3..d1505a1 100644
--- a/monitoring/values-kube-prometheus-stack.yaml
+++ b/monitoring/values-kube-prometheus-stack.yaml
@@ -8,9 +8,17 @@
 #   helm upgrade kube-prometheus-stack prometheus-community/kube-prometheus-stack \
 #     --version 83.2.0 -n monitoring -f values-kube-prometheus-stack.yaml
 #
-# Revisión 2 (2026-07-21) silenció 4 alertas que llevaban meses disparadas sin
-# significar nada — ver el bloque kubeControllerManager/kubeScheduler/kubeProxy
-# y defaultRules.disabled al final.
+# rev 2 (2026-07-21): silenciadas 4 alertas que llevaban meses disparadas sin
+#   significar nada — ver kubeControllerManager/kubeScheduler/kubeProxy y
+#   defaultRules.disabled.
+# rev 3 (2026-07-21): grafana.extraConfigmapMounts. El montaje del ConfigMap
+#   grafana-alerting (reglas + contact points + política → Telegram) se había
+#   añadido A MANO al Deployment y NO lo generaba el chart: sobrevivía solo por
+#   el three-way merge de Helm, que conserva lo que no aparece en ninguno de los
+#   dos renders. Un `helm upgrade --force`, un `kubectl replace` desde el chart,
+#   o reconstruir el release desde este fichero se habrían llevado por delante
+#   TODO el alerting de Grafana, en silencio y sin que los paneles se inmutaran.
+#   Declarado en el chart, el spec resultante es idéntico (no reinició Grafana).
 alertmanager:
   enabled: false
 defaultRules:
@@ -21,6 +29,10 @@ defaultRules:
     alertmanager: false
 grafana:
   adminPassword: admin
+  extraConfigmapMounts:
+  - configMap: grafana-alerting
+    mountPath: /etc/grafana/provisioning/alerting
+    name: grafana-alerting
   grafana.ini:
     server:
       root_url: https://grafana.chemavx.xyz