diff --git a/platform/monitoring/application.yaml b/platform/monitoring/application.yaml
index 52a9393..6458ab3 100644
--- a/platform/monitoring/application.yaml
+++ b/platform/monitoring/application.yaml
@@ -60,6 +60,33 @@ spec:
             requests:
               cpu: 50m
               memory: 128Mi
+        # ── os tres CRITICAL que o k3s faz mentir (2026-09-21) ─────────────
+        #
+        # `KubeProxyDown`, `KubeSchedulerDown` e `KubeControllerManagerDown`
+        # estavam disparando em PERMANENCIA, e sao FALSOS: o k3s roda esses tres
+        # componentes EMBUTIDOS no processo do servidor e nao expoe as portas de
+        # metrica que o chart procura (10249/10259/10257). Nao ha o que consertar
+        # no cluster — o chart e que assume um Kubernetes "de pecas separadas".
+        #
+        # Por que desligar, e nao conviver: **tres criticos permanentes ensinam
+        # todo mundo a ignorar alerta**. No dia em que o Alertmanager existir,
+        # eles seriam a primeira coisa a chegar, e chegariam para sempre — e o
+        # canal nasceria desacreditado.
+        #
+        # Isto NAO desliga vigilancia nenhuma de verdade: com o controlador ou o
+        # scheduler fora, o no inteiro cai, e disso o `up` do kubelet e o
+        # `AthleticMapTenantPodNotReady` falam alto.
+        kubeProxy:
+          enabled: false
+        kubeScheduler:
+          enabled: false
+        kubeControllerManager:
+          enabled: false
+        # Mesmo caso: o etcd do k3s e embutido (SQLite/etcd interno) e nao
+        # responde na porta que o chart espera. Ja vinha desligado no chart para
+        # este arranjo; explicito aqui para nao voltar numa atualizacao.
+        kubeEtcd:
+          enabled: false
   destination:
     server: https://kubernetes.default.svc
     namespace: monitoring
diff --git a/platform/monitoring/athleticmap-rules.yaml b/platform/monitoring/athleticmap-rules.yaml
index 7df48b5..eb822c7 100644
--- a/platform/monitoring/athleticmap-rules.yaml
+++ b/platform/monitoring/athleticmap-rules.yaml
@@ -149,6 +149,35 @@ spec:
             summary: "Mais de 5 eventos de assinatura recusados em 15 min"
             description: "Token do webhook trocado sem atualizar o SealedSecret, ou alguem batendo na rota publica."
 
+    - name: athleticmap.temporada
+      rules:
+        # A faixa etaria e gravada como DATA ABSOLUTA: "Sub-15 = nascidos em 2011"
+        # vale para sempre, e em 2027 essa categoria significa Sub-16. Nada quebra
+        # — as turmas continuam, os alunos continuam, e a categoria passa a mentir.
+        #
+        # `for: 6h` porque isto nao e urgente: e uma conversa com o cliente sobre
+        # remanejar aluno, e nao um incidente. O que nao pode e ninguem saber.
+        - alert: AthleticMapCategoriasForaDaTemporada
+          expr: atm_categorias_fora_da_temporada > 0
+          for: 6h
+          labels:
+            severity: warning
+          annotations:
+            summary: "{{ $labels.tenant }}: {{ $value }} categoria(s) com faixa de outro ano"
+            description: "A virada de temporada NAO e automatica de proposito: mudar a faixa muda quem pertence a qual categoria, e aluno remanejado de madrugada e pior que categoria desatualizada. Confira com o cliente e use virarTemporada."
+
+        # Silencio nao e "esta tudo certo". Quando a conferencia nao roda, o medidor
+        # acima NAO vai a zero — fica sem serie nenhuma —, e e este contador que
+        # denuncia. Duas falhas quer dizer que nao foi soluco de uma noite.
+        - alert: AthleticMapTemporadaNaoConferida
+          expr: increase(atm_temporada_nao_conferida_total[48h]) > 1
+          for: 0m
+          labels:
+            severity: warning
+          annotations:
+            summary: "Ha dois dias nao se consegue conferir a temporada de algum tenant"
+            description: "Banco do tenant fora, credencial trocada ou rede. Veja o log do servico-captacao: kubectl -n plataforma-prod logs deploy/servico-captacao | grep 'nao consegui conferir'"
+
     - name: athleticmap.banco
       rules:
         # O Postgres compartilhado e o PgBouncer atendem TRES tenants: parada