Clarify that Schedules contribute to Active and Retained Storage

docs/best-practices/cost-optimization.mdx

@@ -215,6 +215,18 @@ See the [Data Converter documentation](/default-custom-data-converters#custom-da
 
 For very large payloads or binary data, store data externally (S3 or GCS) and pass references through Workflows.
 
+#### Schedules
+
+Each [Schedule](/schedule) keeps its own backing Workflow Execution open for as long as the Schedule exists, so running Schedules contribute to Active Storage.
+Audit Schedules periodically and delete the ones you no longer need — for example with `temporal schedule delete` (see [Delete](/cli/command-reference/schedule#delete)) or your SDK's delete-Schedule API.
+
+**Considerations**:
+
+- Deleting a Schedule reduces Active Storage, but its closed history still counts toward Retained Storage for your Namespace's retention period.
+- Deleting a Schedule doesn't affect Workflow Executions it already started; those continue to follow normal Active/Retained Storage rules based on their own state.
+
+See [Storage pricing](/cloud/pricing#payg-storage-pricing) for details on how Schedules affect your bill.
+
 ### Retained Storage
 
 Retained Storage applies to closed Workflow History during the retention period.

docs/encyclopedia/workflow/schedule.mdx

@@ -293,6 +293,10 @@ A Workflow started by a Schedule can obtain the details of the failure of the mo
 ### Limitations
 
 Internally, a Schedule is implemented as a Workflow.
+This backing Workflow Execution stays open for as long as the Schedule exists, so each running Schedule contributes to [Active Storage](/cloud/pricing#storage).
+Deleting a Schedule you no longer need reduces this Active Storage footprint, but its closed history still counts toward [Retained Storage](/cloud/pricing#storage) for your Namespace's retention period afterward.
+See [Cost optimization: Storage](/best-practices/cost-optimization#active-storage) for more.
+
 If you're using Elasticsearch, these Workflow Executions are hidden from normal views.
 
 `ListSchedules` and `CountSchedules` are served by the Visibility subsystem. They share the [Visibility API rate limit](/cloud/limits#visibility-api-rate-limit) and are eventually consistent, so a newly created or deleted schedule may not appear in the list right away. For more detail, see [Operations that use Visibility](/visibility#operations-that-use-visibility).

docs/evaluate/temporal-cloud/pricing.mdx

@@ -144,7 +144,7 @@ For additional storage within a calendar month, you are billed for Active and Re
 
 :::tip Storage costs are also affected by Temporal System Workflows that back features such as:
 
-- [Schedules](/schedule): Each Scheduled Workflow contributes to storage usage. Supplied inputs, outputs, and failures all account for the storage usage incurred from Scheduled Workflows.
+- [Schedules](/schedule): Each Schedule keeps its own backing Workflow Execution open for as long as the Schedule exists, so running Schedules contribute to Active Storage. Deleting a Schedule you no longer need reduces this Active Storage footprint, but the closed Workflow Execution still counts toward Retained Storage for your Namespace's retention period. Supplied inputs, outputs, and failures all add to the storage usage a Schedule incurs.
 - [Batch jobs](/cli/command-reference/batch): Batch Workflow executions also consume storage.
 
 These Workflow executions contribute to overall active and retained storage consumption.