From a10227d893b08bf982d67ce5193bbe9b0e84cd33 Mon Sep 17 00:00:00 2001
From: "mintlify[bot]" <109931778+mintlify[bot]@users.noreply.github.com>
Date: Mon, 3 Aug 2026 13:08:20 +0000
Subject: [PATCH 1/2] docs: clarify compute tier behavior during node
 maintenance

---
 scaling/scaling-apps.mdx | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/scaling/scaling-apps.mdx b/scaling/scaling-apps.mdx
index a1d3463d..d16c6773 100644
--- a/scaling/scaling-apps.mdx
+++ b/scaling/scaling-apps.mdx
@@ -284,6 +284,12 @@ Interruptible instances can be interrupted in two ways: the cloud provider can r
 
 Protected instances are excluded from capacity consolidation and never run on preemptible capacity, so they are not interrupted in either case.
 
+### Node Maintenance and Updates
+
+The `compute_tier` setting governs preemption and consolidation only. It does not opt an instance out of node lifecycle events such as OS patches, kernel upgrades, or platform rollouts. Both interruptible and protected instances can be migrated to a new node when the underlying node is cycled for maintenance, and in every case the instance receives SIGTERM and is drained within `response_grace_period` before SIGKILL. See [Graceful Termination](/scaling/graceful-termination) for the shutdown sequence and, for custom runtimes, how to handle SIGTERM so in-flight requests complete instead of returning 502s.
+
+To minimize disruption during a migration, run with `min_replicas >= 2` so at least one replica remains available while another is drained, and set `response_grace_period` to cover your worst-case request duration.
+
 **Choosing a tier:**
 
 - Use `interruptible` (default) for batch workloads, development, or cost-sensitive applications that can tolerate occasional interruptions.

From 28a352a9e6dd1b5b1e4b7567db7370b11a3dd33f Mon Sep 17 00:00:00 2001
From: "mintlify[bot]" <109931778+mintlify[bot]@users.noreply.github.com>
Date: Mon, 3 Aug 2026 13:09:20 +0000
Subject: [PATCH 2/2] docs: improve SEO metadata and split long sentences on
 scaling apps page

---
 scaling/scaling-apps.mdx | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/scaling/scaling-apps.mdx b/scaling/scaling-apps.mdx
index d16c6773..e2bfd19d 100644
--- a/scaling/scaling-apps.mdx
+++ b/scaling/scaling-apps.mdx
@@ -1,6 +1,6 @@
 ---
-title: "Scaling Apps"
-description: "Learn to optimise for cost and performance by scaling out apps"
+title: "Autoscaling apps on Cerebrium"
+description: "Configure replicas, scaling metrics, load balancing, and compute tiers to scale Cerebrium apps for cost, latency, and availability."
 ---
 
 Cerebrium's scaling system automatically manages computing resources to match app demand, from single requests to multiple simultaneous requests, optimizing for both performance and cost.
@@ -286,9 +286,11 @@ Protected instances are excluded from capacity consolidation and never run on pr
 
 ### Node Maintenance and Updates
 
-The `compute_tier` setting governs preemption and consolidation only. It does not opt an instance out of node lifecycle events such as OS patches, kernel upgrades, or platform rollouts. Both interruptible and protected instances can be migrated to a new node when the underlying node is cycled for maintenance, and in every case the instance receives SIGTERM and is drained within `response_grace_period` before SIGKILL. See [Graceful Termination](/scaling/graceful-termination) for the shutdown sequence and, for custom runtimes, how to handle SIGTERM so in-flight requests complete instead of returning 502s.
+The `compute_tier` setting governs preemption and consolidation only. It does not opt an instance out of node lifecycle events such as OS patches, kernel upgrades, or platform rollouts. Both interruptible and protected instances can be migrated to a new node when the underlying node is cycled for maintenance. In every case the instance receives SIGTERM and is drained within `response_grace_period` before SIGKILL.
 
-To minimize disruption during a migration, run with `min_replicas >= 2` so at least one replica remains available while another is drained, and set `response_grace_period` to cover your worst-case request duration.
+See [Graceful Termination](/scaling/graceful-termination) for the shutdown sequence. Custom runtimes must handle SIGTERM themselves so in-flight requests complete instead of returning 502s.
+
+To minimize disruption during a migration, run with `min_replicas >= 2` so at least one replica remains available while another is drained. Set `response_grace_period` to cover your worst-case request duration.
 
 **Choosing a tier:**