Update copy RE disk configuration changes and cooldown (#50844)

## Context

Reverts copy changes from the following PRs:
- Docs: https://github.com/supabase/supabase/pull/42184
- FE: https://github.com/supabase/supabase/pull/47646

Our platform's disk management configuration limitation still follows
the 4 hour cooldown at the moment, doesn't align with AWS's 4 changes in
24 hours rule just yet. This is just to prevent any confusion for now,
and we'll need to update the copy again once behaviour matches AWS on
our BE

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Updates**
* Disk changes are now subject to an approximately four-hour cooldown
after each modification, replacing the previous limit of four changes in
a rolling 24-hour period.
* Disk management screens now show the cooldown status, remaining wait
time, and next available update time.
* Updated platform guides and troubleshooting instructions to reflect
the cooldown and explain available recovery options.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

apps/docs/content/guides/platform/compute-and-disk.mdx

@@ -166,5 +166,5 @@ As mentioned in the Postgres [documentation](https://postgresqlco.nf/doc/en/para
 
 ### Constraints
 
-- You can modify disk attributes up to **four times** within a rolling 24-hour window. A new modification can be initiated as soon as the previous one completes. If you reach this limit, you will encounter throttling and must wait for the rolling 24-hour window to permit further adjustments.
+- After **any** disk attribute change, there is a cooldown period of approximately four hours before you can make further adjustments. During this time, no changes are allowed. If you encounter throttling, you’ll need to wait until the cooldown period concludes before making additional modifications.
 - You can increase disk size but cannot decrease it.

apps/docs/content/guides/platform/database-size.mdx

@@ -87,9 +87,7 @@ Supabase uses network-attached storage to balance performance with scalability.
 
 Projects on the Pro Plan and higher have auto-scaling disks.
 
-Disk size expands automatically when the database reaches 90% of the allocated disk size. The disk is expanded to be 50% larger (for example, 8 GB -> 12 GB).
-
-Auto-scaling is limited to four modifications within a rolling 24-hour window. While a new modification can be initiated immediately after the previous one completes, reaching the quota of four resizes within the current rolling 24-hour window will prevent further scaling until the window allows it. If you reach 95% disk utilization and have exhausted your modification quota, your project will enter read-only mode.
+Disk size expands automatically when the database reaches 90% of the allocated disk size. The disk is expanded to be 50% larger (for example, 8 GB -> 12 GB). Auto-scaling is limited to four modifications within a rolling 24-hour window. If you reach 95% disk utilization and have exhausted your modification quota, your project will enter read-only mode.
 
 <Admonition type="note">
 
@@ -103,7 +101,7 @@ Disk size can also be manually expanded on the [Database Settings page](/dashboa
 
 You may want to import a lot of data into your database which requires multiple disk expansions. for example, uploading more than 1.5x the current size of your database storage will put your database into [read-only mode](#read-only-mode). If so, it is highly recommended you increase the disk size manually on the [Database Settings page](/dashboard/project/_/database/settings).
 
-Due to restrictions on the underlying cloud provider, disk modifications are limited to four operations within a rolling 24-hour window. While a new modification can be initiated as soon as the previous one completes, you will be unable to make further adjustments if you reach this rolling 24-hour limit until the rolling 24-hour window permits it.
+Due to restrictions on the underlying cloud provider, disk expansions can occur only once every four hours. During the four hour cool down window, the disk cannot be resized again.
 
 </Admonition>
 

apps/docs/content/troubleshooting/high-cpu-and-slow-queries-with-error-must-be-a-superuser-to-terminate-superuser-process.mdx

@@ -50,7 +50,7 @@ Since the wraparound prevention autovacuum cannot be stopped, the best approach
 2.  **Increase Disk Throughput/IOPS:**
     - **Action:** If disk I/O utilization is also consistently high (e.g., near 100%), consider temporarily increasing your disk's provisioned IOPS and throughput.
     - **Why it helps:** Autovacuum is an I/O-intensive operation, involving a lot of reading and writing. Higher disk performance can significantly speed up the process.
-    - **Considerations:** Cloud providers may limit the number of disk modifications (e.g., up to four in a rolling 24-hour window). You can start a new modification immediately after the previous one finishes, provided you have not exceeded this rolling 24-hour quota.
+    - **Considerations:** Cloud providers often have limitations, such as a cooldown period (e.g., 4 hours) between disk modification operations.
 
 ## Monitoring progress and future prevention
 

apps/docs/content/troubleshooting/how-to-bypass-cooldown-period.mdx

@@ -1,22 +1,20 @@
 ---
-title = "How to bypass modification limits"
+title = "How to bypass cooldown period"
 topics = [ "platform" ]
-keywords = [ "modification limits", "disk resize" ]
+keywords = [ "cooldown", "disk resize" ]
 database_id = "6f6a34a6-ac3f-4fba-9c70-4f4b8c7aeda7"
 ---
 
-This limit is not a Supabase limitation. It is rooted in how Amazon EBS (the underlying storage for our databases) manages volume modifications. AWS allows up to four modifications per volume within a rolling 24-hour window. While you can start a new modification immediately after a previous one completes, AWS enforces a quota that prevents a fifth modification within that 24-hour period to ensure data integrity and volume stability.
+This cooldown isn't an arbitrary Supabase restriction — it's rooted in how Amazon EBS (the underlying storage for our databases) limits volume modifications to up to four times within a rolling 24-hour window. To keep this predictable, Supabase enforces a 4-hour cooldown after each manual disk modification (e.g. increasing size, changing type, or IOPS) before allowing another one on the same volume. This helps ensure data integrity and stability of the volume under load.
 
-From the [**AWS docs**](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVolume.html):
+See the [**AWS docs**](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVolume.html) for more on how Amazon EBS itself throttles volume modifications.
 
-> After you initiate a volume modification, you must wait for that modification to reach the completed state before you can initiate another modification for the same volume. You can modify a volume up to four times within a rolling 24-hour period, as long as the volume is in the in-use or available state, and all previous modifications for that volume are completed. If you exceed this limit, you get an error message that indicates when you can perform your next modification.
+There are a few options to work around the cooldown, depending on the state of your database:
 
-There are a few options to work around this limit if you have already used your four modifications and need to make further adjustments:
-
-1.  **Restore to a new project**: This spins up a new instance with a new disk, bypassing the 24-hour quota entirely. It’s a great option if you're okay with a new project and project refactoring. [**Docs: restoring to a new project**](/docs/guides/platform/backups#restore-to-a-new-project).
-2.  **pg_upgrade**: Our [**pg_upgrade**](/docs/guides/platform/upgrading) implementation migrates your data to a new disk, which resets the modification count. The main requirement here is that the database must be operational - pg_upgrade can't run if your database is in a degraded or inaccessible state.
+1.  **Restore to a new project**: This spins up a new instance with a new disk, bypassing the cooldown entirely. It’s a great option if you're okay with a new project and project refactoring. [**Docs: restoring to a new project**](/docs/guides/platform/backups#restore-to-a-new-project).
+2.  **pg_upgrade**: Our [**pg_upgrade**](/docs/guides/platform/upgrading) implementation migrates your data to a new disk, which skips the cooldown. The main requirement here is that the database must be operational - pg_upgrade can't run if your database is in a degraded or inaccessible state.
 3.  **Pause and Restore**: This also migrates to a new disk but is only available for projects on the Free plan. If you're not on the Free plan, you'd need to [**transfer your project to an organization on the Free plan**](/docs/guides/platform/project-transfer) first.
 
-If the database is down or locked in a bad state (e.g., corrupted or stuck during resize), and you have hit the modification limit, the only path forward is to wait until the rolling 24-hour window allows for another modification.
+If the database is down or locked in a bad state (e.g., corrupted or stuck during resize), the only path forward is to wait until the cooldown expires and the disk resize job completes in the queue.
 
 More on this in our doc here: [**https://supabase.com/docs/guides/platform/database-size#disk-size**](/docs/guides/platform/database-size#disk-size).

apps/studio/components/interfaces/DiskManagement/DiskManagementForm.sections.tsx

@@ -297,7 +297,7 @@ export function AdvancedSection({
                 isDiskTooSmallForCustomIops && !disableIopsThroughputConfig && !disableDiskInputs
               }
               title="Increase disk size to adjust IOPS or throughput"
-              description={`This disk is too small to update IOPS or throughput, since gp3 volumes are capped at 500 IOPS per GB with a 3,000 IOPS minimum. Resizing to ${suggestedDiskSizeForCustomIops} GB unlocks custom IOPS and throughput, and leaves headroom for further adjustments (disk config changes are limited to 4 within a rolling 24-hour window).`}
+              description={`This disk is too small to update IOPS or throughput, since gp3 volumes are capped at 500 IOPS per GB with a 3,000 IOPS minimum. Resizing to ${suggestedDiskSizeForCustomIops} GB unlocks custom IOPS and throughput, and leaves headroom for further adjustments (disk config changes are locked for 4 hours after each resize).`}
               actions={
                 !disableDiskSizeInput ? (
                   <Button

apps/studio/components/interfaces/DiskManagement/DiskManagementForm.tsx

@@ -221,7 +221,7 @@ export function DiskManagementForm({
     DISK_LIMITS[DiskType.GP3].minIops
   )
   // Suggested target when prompting a resize, sits above the floor so users
-  // aren't pinned at the minimum between disk-config modifications.
+  // aren't pinned at the minimum during the 4-hour disk-config cooldown.
   const suggestedDiskSizeForCustomIops = PLAN_DETAILS.pro.includedDiskGB.gp3
   const isDiskTooSmallForCustomIops =
     watchedStorageType === 'gp3' && watchedTotalSize < minDiskSizeForCustomIops

apps/studio/components/interfaces/DiskManagement/DiskManagementReviewAndSubmitDialog/DiskManagementReviewAndSubmitDialog.hooks.ts

@@ -180,7 +180,7 @@ export function useDiskManagementReviewChanges(
     Number(iopsPrice.newPrice) !== Number(iopsPrice.oldPrice) ||
     Number(throughputPrice.newPrice) !== Number(throughputPrice.oldPrice)
 
-  // Show cooldown warning whenever any disk attribute that counts toward the 24-hour modification limit changes
+  // Show cooldown warning whenever any disk attribute that enforces the 4-hour lock changes
   const anyDiskAttributeChange = hasIOPSChanges || hasStorageTypeChanges || hasTotalSizeChanges
 
   // Show extended downtime warning when resizing to/from a size below large

apps/studio/components/interfaces/DiskManagement/DiskManagementReviewAndSubmitDialog/DiskManagementReviewAndSubmitDialog.tsx

@@ -188,7 +188,7 @@ export const DiskManagementReviewAndSubmitDialog = ({
                 label="IOPS"
                 description={
                   anyDiskAttributeChange && !hasTotalSizeChanges && !hasStorageTypeChanges
-                    ? 'Disk attributes, including IOPS and disk size, may only be modified 4 times within a rolling 24-hour window. A new modification can be started as soon as the previous one completes.'
+                    ? 'Disk attributes, including IOPS and disk size, will be locked for 4 hours after this change.'
                     : undefined
                 }
               >
@@ -217,7 +217,7 @@ export const DiskManagementReviewAndSubmitDialog = ({
             {(hasTotalSizeChanges || hasStorageTypeChanges) && (
               <BreakdownRow
                 label="Disk size"
-                description="You can modify disk attributes up to 4 times within a rolling 24-hour window."
+                description="For 4 hours after changes you will not be able to modify disk attributes."
               >
                 <div className="flex flex-col items-end gap-0.5">
                   <ValueChange

apps/studio/components/interfaces/DiskManagement/ui/DiskCountdownRadial.tsx

@@ -51,10 +51,12 @@ export function DiskCountdownRadial() {
               <CountdownTimerRadial progress={progressPercentage} />
               <div className="flex flex-col gap-2">
                 <div>
-                  <p className="text-foreground text-sm p-0">Disk modification limit reached</p>
+                  <p className="text-foreground text-sm p-0">
+                    4-hour cooldown period is in progress
+                  </p>
                   <p className="text-foreground-lighter text-sm p-0">
-                    You can modify disk attributes up to 4 times within a rolling 24-hour window.
-                    You'll be able to make changes again once the window allows it.
+                    You can't modify your disk configuration again until the 4-hour cool down period
+                    ends.
                   </p>
                 </div>
                 <CountdownTimerSpan seconds={remainingTime} />

apps/studio/components/interfaces/Settings/Database/DiskSizeConfigurationModal.tsx

@@ -180,16 +180,16 @@ const DiskSizeConfigurationModal = ({
                 <DialogSection className="w-full space-y-4">
                   <Alert variant={isAbleToResizeDatabase ? 'default' : 'warning'}>
                     <Info size={16} />
-                    <AlertTitle>
-                      Disk modifications are limited to 4 per rolling 24-hour window
-                    </AlertTitle>
+                    <AlertTitle>This operation is only possible every 4 hours</AlertTitle>
                     <AlertDescription>
                       <div className="mb-4">
                         {isAbleToResizeDatabase
-                          ? `You can modify disk attributes up to 4 times within a rolling 24-hour window. A new modification can be started as soon as the previous one completes.`
+                          ? `Upon updating your disk size, the next disk size update will only be available from ${dayjs().format(
+                              'DD MMM YYYY, HH:mm (ZZ)'
+                            )}`
                           : `Your database was last resized at ${dayjs(lastDatabaseResizeAt).format(
                               'DD MMM YYYY, HH:mm (ZZ)'
-                            )}. You've reached the disk modification limit for now — you can resize again in approximately ${formattedTimeTillNextAvailableResize}.`}
+                            )}. You can resize your database again in approximately ${formattedTimeTillNextAvailableResize}`}
                       </div>
                       <Button asChild iconRight={<ExternalLink size={14} />}>
                         <Link href={`${DOCS_URL}/guides/platform/database-size#disk-management`}>