diff --git a/docs/docs/managing-flags/_category_.json b/docs/docs/managing-flags/_category_.json
new file mode 100644
index 000000000000..e2ce7fc8f7af
--- /dev/null
+++ b/docs/docs/managing-flags/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Managing Flags",
+    "position": 10
+}
\ No newline at end of file
diff --git a/docs/docs/managing-flags/core-management.md b/docs/docs/managing-flags/core-management.md
new file mode 100644
index 000000000000..4b97095352e6
--- /dev/null
+++ b/docs/docs/managing-flags/core-management.md
@@ -0,0 +1,90 @@
+---
+title: Basic Flag Management
+sidebar_label: Basic Flag Management
+sidebar_position: 1
+---
+
+Feature flags in Flagsmith are used to categorise and monitor user actions or events, such as detecting spam or abuse. This guide covers how to create, edit, clone, and delete flags in your project.
+
+---
+
+## Creating a Feature Flag
+
+To create a new feature flag:
+
+1. Go to the **Features** section in your dashboard.
+2. Click **Create Feature**.
+3. Enter a descriptive name for your flag (e.g., `new_ui_enabled`).
+4. Fill in the available fields according to the specifications of your feature. Note that these values are applied to all your [environments]. You can edit each environment individually later.
+    - **Enabled by default**: determines the initial state of the flag for all environments. This can be edited for each environment later.
+    - **Value** (optional): additionally to their boolean value, you can choose a format and a value for your flag.
+    - **Tags** (optional): organise your flags by tags or add `protected` to prevent them from accidentally being deleted.
+    - **Description** (optional): add a feature flag description.
+    - **Server-side only**: enabling this prevents your flag from being accessed by client-side SDKs.
+5. Click **Create Feature**.
+
+:::tip
+
+By clicking the **Create A/B/n Test** button, you can define values for A/B testing. To learn more about this operation, refer to the [A/B Testing guide](../advanced-use/ab-testing).
+
+:::
+
+---
+
+## Editing a Feature Flag
+
+You create feature flags once per project, but you edit them within each environment. To edit an existing feature flag:
+
+1. While on the **Environments** tab on the dashboard, use the dropdown to select the environment where you want to apply the changes.
+2. Locate the feature flag you want to edit and click on it. You can use the search bar to find the feature flag by its name.
+
+:::tip
+
+If you just want to toggle the feature flag *on* or *off*, use the switch under the **View** column in the list view.
+
+:::
+
+3. On the **Value** tab, you can set the feature flag to be on or off, as well as edit a value for it. Click **Update Feature Value** to save your changes.
+4. Optionally, create segment-specific feature flags and define **segment overrides**. Refer to the documentation to learn more about [segments](../basic-features/segments.md). Save any changes by clicking the **Update Segment Overrides** button.
+5. On the **Settings** tab, you can:
+    - Add tags to your feature flag.
+    - Assign it to specific *users* and *groups*.
+    - Update the feature flag's description.
+    - Mark the feature flag as **Server-side only** to prevent it from being accessed by client-side SDKs.
+    - Set the **Archived** status to filter the feature flag as no longer relevant. Note that the feature flag will still be returned by the endpoint as before.
+  Click **Update Settings** to save your changes.
+
+:::tip
+
+Changes made in the **Settings** tab affect all environments. Changes made in other tabs while editing a feature flag are valid only for the selected environment.
+
+:::
+
+---
+
+## Deleting a Feature Flag
+
+To delete a feature flag:
+
+1. In the **Features** section, locate the feature flag you want to remove and click the **three dots** icon on the right.
+2. Select the **Remove feature** option.
+3. Type in the name of the feature flag to confirm the deletion.
+
+:::caution
+
+Deleting a feature flag is permanent and cannot be undone. Make sure your applications do not contain any reference to this feature flag before confirming deleting it.
+
+:::
+
+---
+
+## Troubleshooting
+
+### Feature Flags Not Updating
+
+- Make sure you have saved your changes in each tab of the edit feature flag panel.
+- Check that you are in the correct project and environment.
+
+### Permission Issues
+
+- You may need additional permissions to create, edit, clone, or delete feature flags. If you see permission errors or options are disabled, contact your Flagsmith administrator to review your access rights. For more information, see the [Permissions and Roles](../system-administration/rbac.md) page.
diff --git a/docs/docs/managing-flags/manage-flags/_category_.json b/docs/docs/managing-flags/manage-flags/_category_.json
new file mode 100644
index 000000000000..ba5303ed3b40
--- /dev/null
+++ b/docs/docs/managing-flags/manage-flags/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Manage Flags",
+    "position": 10
+}
\ No newline at end of file
diff --git a/docs/docs/managing-flags/manage-flags/feature-health-metrics.md b/docs/docs/managing-flags/manage-flags/feature-health-metrics.md
new file mode 100644
index 000000000000..9d4c0cda6b03
--- /dev/null
+++ b/docs/docs/managing-flags/manage-flags/feature-health-metrics.md
@@ -0,0 +1,119 @@
+---
+title: Feature Health Metrics
+sidebar_label: Feature Health Metrics
+sidebar_position: 4
+---
+
+Feature health enables you to monitor observability metrics within Flagsmith, specifically in relation to your features and environments. When your observability provider sends alert notifications, Flagsmith can mark features (and optionally environments) as **unhealthy**, providing details about the alerts. This assists your team in responding quickly and making informed decisions.
+
+:::info
+
+Feature Health is in Beta, please email support@flagsmith.com or chat with us <a href="#" class="open-chat" data-crisp-chat-message="Hello, I'm interested in joining the feature health beta.">here</a> if you'd like to join. 
+
+:::
+
+## Prerequisites
+
+- You must have a supported observability provider (see below).
+- You need admin access to your Flagsmith project settings.
+
+---
+
+## How to enable Feature Health
+
+1. Go to your **Project Settings** in Flagsmith.
+2. Navigate to the **Feature Health** section.
+3. Choose your desired provider from the **Provider Name** drop-down menu (e.g., Grafana/Prometheus Alertmanager or Sample).
+4. Click **Create** and copy the webhook URL.
+
+---
+
+## How to integrate with Feature Health providers
+
+### Grafana / Prometheus Alertmanager
+
+[Learn more](/integrations/apm/grafana/#feature-health-provider-setup) about configuring Grafana / Prometheus Alertmanager feature health provider.
+
+### Sample Provider
+
+We provide a Sample Provider for your custom integrations. To create a Sample Feature Health webhook:
+
+1. Go to Project Settings > Feature Health.
+2. Select "Sample" from the Provider Name drop-down menu.
+3. Click Create and copy the webhook URL.
+
+You can use the webhook in your custom integration. Refer to the payload schema below:
+
+```json
+{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "title": "SampleEvent",
+  "type": "object",
+  "properties": {
+    "environment": {
+      "type": "string"
+    },
+    "feature": {
+      "type": "string"
+    },
+    "status": {
+      "type": "string",
+      "enum": ["healthy", "unhealthy"]
+    },
+    "reason": {
+      "$ref": "#/definitions/FeatureHealthEventReason"
+    }
+  },
+  "required": ["feature", "status"],
+  "definitions": {
+    "FeatureHealthEventReason": {
+      "type": "object",
+      "properties": {
+        "text_blocks": {
+          "type": "array",
+          "items": {
+            "$ref": "#/definitions/FeatureHealthEventReasonTextBlock"
+          }
+        },
+        "url_blocks": {
+          "type": "array",
+          "items": {
+            "$ref": "#/definitions/FeatureHealthEventReasonUrlBlock"
+          }
+        }
+      }
+    },
+    "FeatureHealthEventReasonTextBlock": {
+      "type": "object",
+      "properties": {
+        "text": {
+          "type": "string"
+        },
+        "title": {
+          "type": "string"
+        }
+      },
+      "required": ["text"]
+    },
+    "FeatureHealthEventReasonUrlBlock": {
+      "type": "object",
+      "properties": {
+        "url": {
+          "type": "string"
+        },
+        "title": {
+          "type": "string"
+        }
+      },
+      "required": ["url"]
+    }
+  }
+}
+```
+
+---
+
+## What's next?
+
+- For more on observability integrations, see the [integrations documentation](/integrations/).
+- Need help or want to join the Beta? Contact [support@flagsmith.com](mailto:support@flagsmith.com) or chat with us in-app.
diff --git a/docs/docs/managing-flags/manage-flags/scheduled-flags.md b/docs/docs/managing-flags/manage-flags/scheduled-flags.md
new file mode 100644
index 000000000000..87394d4c4e3e
--- /dev/null
+++ b/docs/docs/managing-flags/manage-flags/scheduled-flags.md
@@ -0,0 +1,55 @@
+---
+title: Scheduled Flags
+sidebar_label: Scheduled Flags
+sidebar_position: 3
+---
+
+Scheduled flags allow you to queue and automatically apply changes to feature flags at a specified future time, eliminating the need for manual intervention at the exact moment of change. This page shows you how to schedule flag changes.
+
+There are two methods for creating a scheduled feature flag change:
+
+- As part of a change request.
+- Directly while editing a feature flag, if change requests are not enforced.
+
+## Prerequisites
+
+- To schedule feature flag changes with a change request, you must [have change requests enabled](../../advanced-use/change-requests.md) in your environment. This is not necessary to directly schedule changes when editing a flag.
+- Scheduled flags are available only for our **Scale-up** and **Enterprise** plans.
+
+---
+
+## How to create a Scheduled Flag change as part of a Change Request
+
+1. Ensure your environment has change requests enabled.
+2. Attempt to change a feature flag value within the environment. You will be prompted to create a new change request.
+3. Fill in the following details:
+   - The title of the change request
+   - (Optional) A description of the reason for the change request
+   - The date and time at which you want the feature flag change to take effect
+4. Submit the change request. The scheduled change will appear in the change request area as 'Pending'.
+
+---
+
+## How to create a stand-alone scheduled feature flag change
+
+If change requests are not enabled for your environment, you can schedule a flag change directly:
+
+1. In the Features list view, go to the feature flag you want to edit.
+2. Choose the new value or state for the feature flag.
+3. Click the **Schedule Update** button to set the date and time for the change to take effect.
+4. Save your changes. The scheduled change will be queued and applied automatically at the specified time.
+
+---
+
+## Scheduled Flags and Change Requests
+
+Scheduled feature flags awaiting application will be listed in the change request area as 'Pending'.
+
+Once the scheduled date and time have passed and the feature flag change has been applied, the scheduled feature flag will automatically move to the 'Closed' list in the change request area.
+
+---
+
+## What's next?
+
+- To learn more about managing and approving changes to your feature flags, see the [change requests](../../advanced-use/change-requests.md) page.
+- To learn how to monitor the performance and health of your feature flags, see the [feature health metrics](./feature-health-metrics.md) page.
diff --git a/docs/docs/managing-flags/rollout/_category_.json b/docs/docs/managing-flags/rollout/_category_.json
new file mode 100644
index 000000000000..53322d2ee977
--- /dev/null
+++ b/docs/docs/managing-flags/rollout/_category_.json
@@ -0,0 +1,4 @@
+{
+    "label": "Rollout",
+    "position": 10
+}
\ No newline at end of file
diff --git a/docs/docs/managing-flags/rollout/rollout-by-attribute.md b/docs/docs/managing-flags/rollout/rollout-by-attribute.md
new file mode 100644
index 000000000000..6bd079cdd48b
--- /dev/null
+++ b/docs/docs/managing-flags/rollout/rollout-by-attribute.md
@@ -0,0 +1,58 @@
+---
+title: Rollout by Attribute
+sidebar_label: Rollout by Attribute
+sidebar_position: 1
+---
+
+This guide explains how to enable a feature for specific users based on their attributes (traits) in Flagsmith using segments and segment overrides. Attributes can include user role, subscription plan, application version, or device type.
+
+## Prerequisites
+
+- A Flagsmith project and environment.
+- A feature flag created in your project.
+- Your application's [Flagsmith SDK](../../clients/index.md) integrated and configured.
+
+## Steps
+
+### 1. Identify and Send User Traits
+
+Ensure your application is identifying users and sending their relevant attributes (traits) to Flagsmith. For example, you might send traits like `plan`, `email`, `platform`, or `version` using your SDK:
+
+```javascript
+flagsmith.identify('user_123');
+flagsmith.setTrait('plan', 'pro');
+flagsmith.setTrait('version', '5.4.1');
+```
+
+### 2. Create a Segment Based on Attribute(s)
+
+1. Go to the **Segments** section in the Flagsmith dashboard.
+2. Create a new segment and add rules that match the attribute(s) you want to target. For example:
+  - `plan = pro`
+  - `email Contains @yourcompany.com`
+  - `version SemVer >= 5.4.0`
+3. You can combine multiple rules for more precise targeting.
+
+### 3. Apply a Segment Override to Your Feature Flag
+
+1. In the environment where you want to apply the rollout, go to the **Features** section and select the feature flag you want to roll out.
+2. Navigate to the **Segment Overrides** tab.
+- Select the segment you created in the dropdown and set the desired feature flag state or value for users in that segment.
+- Save your changes.
+
+Done! Now you can test with users who match (and don’t match) the segment to ensure the feature is enabled/disabled as expected.
+
+---
+
+## Advanced Use Cases
+
+- You can combine attribute rules with a **% split** rule for staged rollouts (e.g., only 10% of "pro" users).
+- You can use operators such as `In`, `SemVer`, `Modulo`, etc., for more complex targeting.
+
+---
+
+## What's next
+
+- Read the [segments documentation](../../basic-features/segments.md) to understand how they work and their relationship with overrides.
+- See the [staged feature rollouts guide](./rollout-by-percentage.md) to combine attribute rules with percentage-based rollouts for gradual releases.
+- Understand [managing identities](../../basic-features/managing-identities.md) to ensure consistent user identification and attribute management across your application.
diff --git a/docs/docs/managing-flags/rollout/rollout-by-percentage.md b/docs/docs/managing-flags/rollout/rollout-by-percentage.md
new file mode 100644
index 000000000000..a89bca38b95b
--- /dev/null
+++ b/docs/docs/managing-flags/rollout/rollout-by-percentage.md
@@ -0,0 +1,79 @@
+---
+title: Rollout by Percentage
+sidebar_label: Rollout by Percentage
+sidebar_position: 2
+---
+
+**Rollouts by percentage** (also known as staged feature rollouts) allow you to test a new feature with a small subset of your user base. If you are happy with the feature, you can increase the percentage of users that see the feature until it is available to your entire user base.
+
+This method increases confidence in rolling out a new feature. If issues arise, you can disable the feature flag, thus hiding the feature flag within your application.
+
+## Prerequisites
+
+:::important
+
+Staged rollouts **_only_** come into effect if you are getting the flags for a particular identity. If you are just retrieving the flags for an environment without passing in an identity, your user will never be included in the "% split" segment.
+
+:::
+
+Before you begin, make sure you have:
+
+- A feature flag created in your project.
+- Your application's [Flagsmith SDK](../../clients/index.md) integrated and configured.
+- **Identifying users in your application:** You must identify users so that percentage rollouts are evaluated per user. For example:
+
+  ```javascript
+  flagsmith.identify('user_123');
+  ```
+
+- (Optional) Any user traits you want to use for more advanced segment rules.
+
+---
+
+## How to Rollout by Percentage
+
+### 1. Create a segment with a percentage split rule
+
+- Go to the **Segments** section in the Flagsmith dashboard.
+- Create a new segment.
+- Add a rule defined with the **% Split** condition. Specify a value between 1 and 100 to define what percentage of your user base is included within this segment.
+- You can optionally use the **% Split** rule alongside other segment rules.
+
+### 2. Connect the Segment to a Feature Flag
+
+- Go to the **Features** section and select the feature you want to roll out.
+- In the environment where you want to apply the rollout, go to the **Segment Overrides** tab.
+- Add the segment you created and set the desired feature flag state or value for users in that segment.
+
+### 3. Save and Monitor
+
+- Save your changes.
+- Monitor the rollout. If all goes well, gradually increase the **% Split** value to roll out the feature to more users over time.
+- If issues arise, you can quickly disable the feature flag for all users by removing the override or setting the feature flag to disabled.
+
+---
+
+## How it works
+
+Each identity and segment has a unique identifier. These two pieces of data are merged, then hashed, and a floating point value between 0.0 and 1.0 is generated from this hash. This value is then evaluated against the "% split" rule.
+
+### An Example
+
+For a single identity, the following steps are performed:
+
+1. Take the internal segment ID and their internal identity ID and combine them into a single string
+2. Hash that string
+3. Generate a float value between 0 and 1 based on that hash
+
+For every segment/identity combination, a value between 0 and 1 is generated. Due to the hashing algorithm used, there is a consistent spread of values from 0 to 1.
+
+- If the number comes out at `0.351` for a particular identity, and you create a segment % split to be 30%, that identity will **not** be included in that segment because `0.351` is greater than `0.3` (30%).
+- If you then modify the segment to be a 40% split, the identity **will** be in that segment because `0.4 > 0.351`. That way you get a consistent experience as an end-user. This works because the ID of a segment doesn't change after it has been created.
+- A second identity might have their value hash be equal to `0.94`. In that case, they would not be in the segment with the split at either 30% or 40%.
+
+---
+
+## What's next
+
+- Read the [segments documentation](../../basic-features/segments.md) to understand how segments work and how to combine them with percentage splits.
+- See how to [roll out features by user attribute](./rollout-by-attribute.md) for targeted releases.
diff --git a/docs/docs/managing-flags/tagging.md b/docs/docs/managing-flags/tagging.md
new file mode 100644
index 000000000000..cbebe1f37f91
--- /dev/null
+++ b/docs/docs/managing-flags/tagging.md
@@ -0,0 +1,66 @@
+---
+title: Tagging
+sidebar_label: Tagging
+sidebar_position: 2
+---
+
+You can create tags within Flagsmith and tag feature flags in order to organise them. Tags can also be used to filter the list of feature flags in the event that you have a large number of them.
+
+This guide explains how to create and apply tags to feature flags within Flagsmith, as well as some tagging good practices and conventions.
+
+---
+
+## Creating and Applying Tags
+
+You can add tags to feature flags during creation or when editing an existing flag.
+
+### When Creating a Feature Flag
+
+1. Go to the **Features** section in your dashboard.
+2. Click **Create Feature**.
+3. Fill in the feature flag details. In the **Tags** field (optional), enter one or more tags to organise your feature flag. You can also add special tags such as `protected` to prevent accidental deletion.
+4. Click **Create Feature** to save your changes.
+
+### When Editing a Feature Flag
+
+1. In the **Features** section, select the feature flag you want to edit.
+2. Go to the **Settings** tab.
+3. In the **Tags** field, add or remove tags as needed.
+4. Click **Update Settings** to save your changes.
+
+You can quickly find and manage feature flags by using the **tag filter** in the Features list to display only feature flags with specific tags. This is especially useful for large projects with many feature flags.
+
+---
+
+## Tag Conventions
+
+- **General Recommendations:**
+  - Use clear, descriptive tag names (e.g., `beta`, `deprecated`, `marketing`).
+  - Establish a naming convention for your team. For example, use all lowercase, hyphen-separated tags.
+  - Avoid using case-sensitive tags unless necessary. By default, tags are not case-sensitive.
+
+:::info Protected Tags
+
+Tags with the following names will prevent users from being able to delete tagged feature flags via the dashboard:
+
+- `protected`
+- `donotdelete`
+- `permanent`
+
+:::
+
+
+---
+
+## Best Practices for Tag Management
+- Use tags to group related feature flags (e.g., by feature, team, or release).
+- Apply protected tags (`protected`, `donotdelete`, `permanent`) to critical or long-lived feature flags to prevent accidental deletion.
+- Regularly review and update tags to keep your feature flag management organised.
+
+---
+
+## What's Next
+
+- Learn how to configure [tag-based permissions for roles](../system-administration/rbac.md).
+- See more advanced [feature flag management](../advanced-use/flag-management.md) techniques.
+