From cf409d0cba8b40904d73d16d92b4a5a3ab865721 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Tue, 27 May 2025 22:50:22 +0200
Subject: [PATCH] removed duplicated paragraph

---
 deploy-manage/production-guidance/scaling-considerations.md | 2 --
 1 file changed, 2 deletions(-)

diff --git a/deploy-manage/production-guidance/scaling-considerations.md b/deploy-manage/production-guidance/scaling-considerations.md
index 94fcc58e5b..fb2f45560a 100644
--- a/deploy-manage/production-guidance/scaling-considerations.md
+++ b/deploy-manage/production-guidance/scaling-considerations.md
@@ -12,8 +12,6 @@ applies_to:
 
 Knowing when and how to scale your deployment is critical, especially when unexpected workloads hit. Adding more nodes or adjusting resources is not always the best solution. Instead, scaling should be based on real workload patterns and informed decision-making.
 
-In orchestrated or managed deployments, [Autoscaling](/deploy-manage/autoscaling.md) can automatically adjust cluster resources based on demand, reducing operational overhead. However, in self-managed environments, scaling is a manual process, requiring careful planning to adapt to workload changes and ensure the cluster remains performant and resilient.
-
 In orchestrated or managed deployments, [Autoscaling](/deploy-manage/autoscaling.md) can automatically adjust cluster resources based on demand, reducing operational overhead. However, if you choose not to use it, or in self-managed environments, scaling becomes a manual process that requires careful planning to adapt to workload changes and ensure the cluster remains performant and resilient.
 
 ::::{note}