diff --git a/docs/release-notes/8.9.asciidoc b/docs/release-notes/8.9.asciidoc
index aacc9c831d..68dc7e5483 100644
--- a/docs/release-notes/8.9.asciidoc
+++ b/docs/release-notes/8.9.asciidoc
@@ -12,6 +12,44 @@
 * On the new Detection rule monitoring dashboard, total `Rule executions` will not always equal the sum of `Succeeded`, `Warning`, and `Failed` executions. This is expected because rules can write multiple statuses per execution. One typical example is gap detection: if a rule detects a gap in rule execution it will write an intermediate `Failed` status, then continue to run, and write a final status (such as `Warning`) before finishing its execution.
 * Rule changes can't be saved if the rule's action frequency is shorter than the rule's run interval.
 * The `upload` response action does not report the correct amount of available disk space. The correct amount is approximately four gigabytes. 
+* An UI bug can affect the Alerts table's height and make it difficult to view alerts. View the alerts in Timeline or choose one of the following workarounds to readjust the Alerts table:
+** Use the Alerts table **Fields** browser to remove fields until the table width is smaller than its container.
+** Adjust your OS’ zoom settings and refresh the page.
+** Zoom your browser in and then out.
+* Rendering issues will occur if threat indicator match alerts contain nested `file.name` values and the `file.name` column is displayed in the Alerts table. This issue stems from a known bug that occurs when the Alerts table sends a request to the Elasticsearch Fields API (https://github.com/elastic/elasticsearch/issues/97684[#97684]).
++
+NOTE: When customizing the Alerts table, avoid adding or displaying fields that also exist as a nested property within any alert documents.
+
++
+The workaround for this issue depends on the types of alerts displayed in the Alerts table. Choose the case and workaround that's most relevant to you:
+
++
+**Case #1:** The Alerts table does not render during its attempt to display threat indicator match alerts with nested `file.name` fields. To re-render the Alert table, manually edit your browser's local storage:
+
++
+NOTE: These instructions apply to the Google Chrome browser. Adjust the steps based on the type of browser you're using.
+
+. Inspect the Alerts page to open DevTools.
+. Go to *Application -> Storage*, then expand *Local Storage*. 
+. Click the name of your Kibana instance, for example, http://localhost:1234. 
+. Search for the `detection-engine-alert-table-securitySolution-rule-details-gridView` key and copy the key's value.
++
+NOTE: The value you copied is the JSON blob that's used to persist the Alert table's state, including the tables selected columns. 
+
+. Paste the JSON blob into a text file and do the following: 
+.. Remove the `id:file.name` string from the `columns` array.  
+.. Remove the 'file.name' string from the `visibleColumns` array. 
+. Go back DevTools and paste the edited JSON into the value for the `detection-engine-alert-table-securitySolution-rule-details-gridView` key.
+. Click the *Enter* key on your keyboard and refresh the Alerts page. 
++
+
+The Alerts table should re-render correctly, and without the `file.name` column. To avoid further issues, _do not_ re-add the `file.name` field to the table.    
+
++ 
+**Case #2:** The Alerts table renders with empty rows as it attempts to display any alert type and threat indicator match alerts with nested `file.name` fields. To resolve this issue: 
+. Go to the toolbar in the upper-left of the Alerts table and click **Fields*. 
+. Search for the `file.name` field, de-select it, and click *Close*.
+. Refresh the Alerts page. 
 
 [discrete]
 [[breaking-changes-8.9.0]]