diff --git a/content/rancher/v2.x/en/tools/notifiers-and-alerts/_index.md b/content/rancher/v2.x/en/tools/notifiers-and-alerts/_index.md
index ae5aabc6deb..deec63e0391 100644
--- a/content/rancher/v2.x/en/tools/notifiers-and-alerts/_index.md
+++ b/content/rancher/v2.x/en/tools/notifiers-and-alerts/_index.md
@@ -3,15 +3,15 @@ title: Alerts and Notifiers
weight: 5010
---
-Notifiers and Alerts are two features that work together to inform you of events in the Rancher system. Notifiers are objects that you configure to leverage popular IT services, which send you notification of Rancher Events. Alerts are rule sets that trigger when those notifications are sent.
+Notifiers and alerts are two features that work together to inform you of events in the Rancher system. Notifiers are objects that you configure to leverage popular IT services, which send you notification of Rancher events. Alerts are rule sets that trigger when those notifications are sent.
-Notifiers and Alerts are built on top of the [Prometheus Alertmanager](https://prometheus.io/docs/alerting/alertmanager/). Leveraging these tools, Rancher can notify [cluster owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) and [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) of events they need to address.
+Notifiers and alerts are built on top of the [Prometheus Alertmanager](https://prometheus.io/docs/alerting/alertmanager/). Leveraging these tools, Rancher can notify [cluster owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) and [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) of events they need to address.
## Notifiers
Before you can receive [alerts](#alerts), you must configure one or more notifier in Rancher.
-_Notifiers_ are services that inform you of alert events. You can configure notifiers to send alert notifications to staff best suited to take corrective action.
+Notifiers are services that inform you of alert events. You can configure notifiers to send alert notifications to staff best suited to take corrective action.
Notifiers are configured at the cluster level. This model ensures that only cluster owners need to configure notifiers, leaving project owners to simply configure alerts in the scope of their projects. You don't need to dispense privileges like SMTP server access or cloud account access.
@@ -20,7 +20,7 @@ Rancher integrates with a variety of popular IT services, including:
- **Slack**: Send alert notifications to your Slack channels.
- **Email**: Choose email recipients for alert notifications.
- **PagerDuty**: Route notifications to staff by phone, SMS, or personal email.
-- **Webhooks**: Update a webpage with alert notifications.
+- **WebHooks**: Update a webpage with alert notifications.
@@ -35,32 +35,34 @@ Set up a notifier so that you can begin configuring and sending alerts.
1. Select the service you want to use as your notifier, and then fill out the form.
{{% accordion id="slack" label="Slack" %}}
1. Enter a **Name** for the notifier.
-1. Create a Slack Webhook. For instructions, see the [Slack Documentation](https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack).
-1. Enter your Slack Webhook **URL**.
+1. From Slack, create a webhook. For instructions, see the [Slack Documentation](https://get.slack.help/hc/en-us/articles/115005265063-Incoming-WebHooks-for-Slack).
+1. From Rancher, enter your Slack webhook **URL**.
1. Enter the name of the channel that you want to send alert notifications in the following format: `#`.
-1. Click **Test**. If the test is successful, the target Slack channel prints `Slack setting validated`.
+
+ Both public and private channels are supported.
+1. Click **Test**. If the test is successful, the Slack channel you're configuring for the notifier outputs `Slack setting validated`.
{{% /accordion %}}
{{% accordion id="email" label="Email" %}}
1. Enter a **Name** for the notifier.
1. In the **Sender** field, enter an email address available on your mail server that you want to send the notification.
1. In the **Host** field, enter the IP address or host name for your SMTP server. Example: `smtp.email.com`
-1. In the **Port** field, enter the port used for email. TLS typically uses `587` and SSL typically uses `465`. If you're using TLS, make sure **Use TLS** is selected.
+1. In the **Port** field, enter the port used for email. Typically, TLS uses `587` and SSL uses `465`. If you're using TLS, make sure **Use TLS** is selected.
1. Enter a **Username** and **Password** that authenticate with the SMTP server.
-1. In the **Default Recipent** field, enter the email address that you want to receive the notification.
+1. In the **Default Recipient** field, enter the email address that you want to receive the notification.
1. Click **Test**. If the test is successful, Rancher prints `settings validated` and you receive a test notification email.
{{% /accordion %}}
{{% accordion id="pagerduty" label="PagerDuty" %}}
1. Enter a **Name** for the notifier.
-1. Create a PagerDuty WebHook. For instructions, see the [PagerDuty Documentation](https://support.pagerduty.com/docs/webhooks).
-1. Copy the WebHook's **Integration Key**.
-1. Enter the key in the **Service Key** field.
-1. Click **Test**. If the test is successful, your PagerDuty endpoint prints `PageDuty setting validated`.
+1. From PagerDuty, create a webhook. For instructions, see the [PagerDuty Documentation](https://support.pagerduty.com/docs/webhooks).
+1. From PagerDuty, copy the webhook's **Integration Key**.
+1. From Rancher, enter the key in the **Service Key** field.
+1. Click **Test**. If the test is successful, your PagerDuty endpoint outputs `PageDuty setting validated`.
{{% /accordion %}}
-{{% accordion id="webhook" label="Webhook" %}}
+{{% accordion id="webhook" label="WebHook" %}}
1. Enter a **Name** for the notifier.
1. Using the app of your choice, create a webhook URL.
1. Enter your webhook **URL**.
-1. Click **Test**. If the test is successfull, the URL prints `Webhook setting validated`.
+1. Click **Test**. If the test is successfull, the URL you're configuring as a notifier outputs `Webhook setting validated`.
{{% /accordion %}}
1. Click **Add** to complete adding the notifier.
@@ -86,9 +88,9 @@ After you set up notifiers, you can manage them by selecting **Tools > Notifiers
## Alerts
-To keep your clusters and applications healthy and driving your organizational productivity forward, you need stay informed of events occurring in your clusters and projects, both planned and unplanned. To help you stay informed of these events, you can configure alerts.
+To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned. To help you stay informed of these events, you can configure alerts.
-_Alerts_ are sets of rules, chosen by you, to monitor for specific events. The scope for alerts can be set at either the cluster or project level.
+Alerts are sets of rules, chosen by you, to monitor for specific events. The scope for alerts can be set at either the cluster or project level.
### Cluster Alerts vs. Project Alerts
@@ -135,14 +137,14 @@ This alert type monitors for events that affect one of the Kubernetes master com
- **Info**: Least urgent
- Select the urgency level of the alert based on how many nodes fill the role within your cluster. For example, if you have a 5-node cluster, and all 5 nodes run `etcd`, select **Info**. However, if only 1 node in your cluster runs `etcd`, select **Critical**.
+ Select the urgency level based on the importance of the service and how many nodes fill the role within your cluster. For example, if you're making an alert for the `etcd` service, select **Critical**. If you're making an alert for redundant schedulers, **Warning** is more appropriate.
{{% /accordion %}}
{{% accordion id="resource-event" label="Resource Event Alerts" %}}
-This alert type monitors for any event that involves a selected resource type, rather than a unique event.
+This alert type monitors for specific events that are thrown from a resource type.
1. Choose the type of resource event that triggers an alert. The options are:
- - **Normal**: triggers an alert when resource events occur, either expected or unexpected.
+ - **Normal**: triggers an alert when any standard resource event occurs.
- **Warning**: triggers an alert when unexpected resource events occur.
1. Select a resource type from the **Choose a Resource** drop-down that you want to trigger an alert.
@@ -162,7 +164,7 @@ This alert type monitors for any event that involves a selected resource type, r
Select the urgency level of the alert by considering factors such as how often the event occurs or its importance. For example:
- - If you set a normal alert for pods, you're likely to receive alerts often, and individual pods usually self-heal, so select an urgency of **Low**.
+ - If you set a normal alert for pods, you're likely to receive alerts often, and individual pods usually self-heal, so select an urgency of **Info**.
- If you set a warning alert for StatefulSets, its very likely to impact operations, so select an urgency of **Critical**.
@@ -188,9 +190,9 @@ This alert type monitors for events that occur on a specific node.
Select the urgency level of the alert based on its impact on operations. For example, an alert triggered when a node's CPU raises above 60% deems a urgency of **Info**, but a node that is **Not Ready** deems an urgency of **Critical**.
{{% /accordion %}}
{{% accordion id="node-selector" label="Node Selector Alerts" %}}
-This alert type monitors for events that occur on any node on marked with a key value pair. For more information, see the Kubernetes documentation for [NodeSelectors](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector).
+This alert type monitors for events that occur on any node on marked with a label. For more information, see the Kubernetes documentation for [Labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/).
-1. Select the **Node Selector** option, and then click **Add Selector** to enter a nodeSelector key value pair. This nodeSelector should be applied to one or more of your nodes. Add as many selectors as you'd like.
+1. Select the **Node Selector** option, and then click **Add Selector** to enter a key value pair for a label. This label should be applied to one or more of your nodes. Add as many selectors as you'd like.
1. Choose an event to trigger the alert.
@@ -249,7 +251,7 @@ This alert type monitors for the status of a specific pod.
- **Warning**: Normal urgency
- **Info**: Least urgent
- Select the urgency level of the alert based on how many nodes fill the role within your cluster. For example, an stateless pod that's not can be easily replaced, so select **Info**. However, if an important pod isn't scheduled, it may affect operations, so choose **Critical**.
+ Select the urgency level of the alert based on pod state and expendability. For example, an stateless pod that's not can be easily replaced, so select **Info**. However, if an important pod isn't scheduled, it may affect operations, so choose **Critical**.
{{% /accordion %}}
{{% accordion id="workload" label="Workload Alerts" %}}
This alert type monitors for the availability of a workload.
@@ -264,13 +266,13 @@ This alert type monitors for the availability of a workload.
- **Warning**: Normal urgency
- **Info**: Least urgent
- Select the urgency level of the alert based on the percentage. For example, if you set the alert to 100%, choose **Info**, as the workload is still readily available. If you choose 20%, choose **Critical**, as your app is at risk of going offline.
+ Select the urgency level of the alert based on the percentage you choose and the importance of the workload.
{{% /accordion %}}
{{% accordion id="workload-selector" label="Workload Selector Alerts" %}}
This alert type monitors for the availability of all workloads marked with tags that you've specified.
-1. Select the **Workload Selector** option, and then click **Add Selector** to enter a key value pair. If one of the workloads drops below your specifications, an alert is triggered. This pair should be applied to one or more of your workloads.
+1. Select the **Workload Selector** option, and then click **Add Selector** to enter the key value pair for a label. If one of the workloads drops below your specifications, an alert is triggered. This label should be applied to one or more of your workloads.
1. Select the urgency level of the of alert.
@@ -278,7 +280,8 @@ This alert type monitors for the availability of all workloads marked with tags
- **Warning**: Normal urgency
- **Info**: Least urgent
- Select the urgency level of the alert based on the percentage. For example, if you set the alert to 100%, choose **Info**, as the workloads marked with the selector are still readily available. If you choose 20%, choose **Critical**, as a workload marked with the selector at risk of going offline.
+ Select the urgency level of the alert based on the percentage you choose and the importance of the workload.
+
{{% /accordion %}}
1. Finally, choose the notifiers that send you alerts.