diff --git a/learn/incidents/anatomy-of-a-status-page.mdx b/learn/incidents/anatomy-of-a-status-page.mdx
index 902cfccf..a8e2e182 100644
--- a/learn/incidents/anatomy-of-a-status-page.mdx
+++ b/learn/incidents/anatomy-of-a-status-page.mdx
@@ -57,7 +57,7 @@ The basic technical requirements (fast loading pages, manual edits permitted, et
 
 **3. Clear infographics** - a status page should be able to take complex historical data and turn it into a clear history for the viewer. Some kind of graphing library should represent high level status data visually.
 
-**4. Incidents should be organized into services** - for Checkly’s Status Pages, all alerts are [classified ahead of time into services](/communicate/status-pages/overview#services). We don’t want to present our product as a monolith, nor should we print inscrutable internal labels. With this organization, we can present sections on a single status page, or multiple separate status pages with groupings of services.
+**4. Incidents should be organized into services** - for Checkly’s Status Pages, you organize each page into [components](/communicate/status-pages/overview#components) ahead of time, and on Team and Enterprise plans, [automation rules](/communicate/status-pages/overview#automatically-creating-incidents) match failing checks by tag and open an incident on the components you choose. We don’t want to present our product as a monolith, nor should we print inscrutable internal labels. With this organization, we can present sections on a single status page, or multiple separate status pages with groupings of services.
 
 **5. Subscription service** - Users should subscribe to only the pages they care about.