use alerting concepts diagram with sequence, and update docs to expla…

…in the sequence (#86699)

docs/user/alerting/alerting-getting-started.asciidoc

@@ -123,14 +123,15 @@ image::images/alert-concepts-connectors.svg[Connectors provide a central place t
 [float]
 === Summary
 
-An _alert_ consists of conditions, _actions_, and a schedule. When conditions are met, _alert instances_ are created that render _actions_ and invoke them. To make action setup and update easier, actions refer to _connectors_ that centralize the information used to connect with {kib} services and third-party integrations.
+An _alert_ consists of conditions, _actions_, and a schedule. When conditions are met, _alert instances_ are created that render _actions_ and invoke them. To make action setup and update easier, actions refer to _connectors_ that centralize the information used to connect with {kib} services and third-party integrations. The following example ties these concepts together: 
 
 image::images/alert-concepts-summary.svg[Alerts, actions, alert instances and connectors work together to convert detection into action]
 
-* *Alert*: a specification of the conditions to be detected, the schedule for detection, and the response when detection occurs. 
-* *Action*: the response to a detected condition defined in the alert. Typically actions specify a service or third party integration along with alert details that will be sent to it. 
-* *Alert instance*: state tracked by {kib} for every occurrence of a detected condition. Actions as well as controls like muting and re-notification are controlled at the instance level. 
-* *Connector*: centralized configurations for services and third party integration that are referenced by actions. 
+. Anytime an *alert*'s conditions are met, an *alert instance* is created.  This example checks for servers with average CPU > 0.9. Three servers meet the condition, so three instances are created. 
+. Instances create *actions* as long as they are not muted or throttled. When actions are created, the template that was setup in the alert is filled with actual values.  In this example three actions are created, and the template string {{server}} is replaced with the server name for each instance. 
+. {kib} invokes the actions, sending them to a 3rd party *integration* like an email service.
+. If the 3rd party integration has connection parameters or credentials, {kib} will fetch these from the *connector* referenced in the action. 
+
 
 [float]
 [[alerting-concepts-differences]]