docs: clarify notifiers and alerts

redirections.yml

@@ -861,6 +861,9 @@
   - old: "/databases/postgresql/guides/upgrading"
     new: "/databases/postgresql/shared-resources/guides/upgrading"
 
+  - old: "/platform/app/notification"
+    new: "/platform/app/notifiers"
+
 obsolete:
   - "/how-to-migrate-from-cloudcontrol/"
   - "/how-to-migrate-from-shelly-cloud/"

src/_posts/databases/about/2000-01-01-backup-policies.md

@@ -151,7 +151,7 @@ The following events are available to monitor the backups:
 | `database_backup_succeeded` | A database backup has been successfully completed |
 | `database_backup_failed`    | A database backup has failed                      |
 
-To learn more about events and notifications, please visit the page dedicated to [app notifications]({% post_url platform/app/2000-01-01-notification %}).
+To learn more about events and notifiers, please visit the page dedicated to [app notifiers]({% post_url platform/app/2000-01-01-notifiers %}).
 
 ## Restoring a backup
 

src/_posts/databases/about/2000-01-01-maintenance-windows.md

@@ -213,7 +213,7 @@ later time.
 
 By default, owner and collaborators receive email notifications one day before
 a scheduled maintenance execution. This notification system operates via the
-[App notifications]({% post_url /platform/app/2000-01-01-notification %})
+[App notifiers]({% post_url platform/app/2000-01-01-notifiers %})
 feature and the "default notifier" which is configured for each app. Please
 check if it is still active or configure another notifier for this purpose.
 It can easily be configured to suit your preferences. For instance, if you

src/_posts/platform/app/2000-01-01-alerts.md

@@ -1,41 +1,80 @@
 ---
 title: Alerts About Application Metrics
 nav: Alerts
-modified_at: 2018-03-27 00:00:00
+modified_at: 2026-05-05 00:00:00
 tags: app alert metrics
+index: 37
 ---
 
-Scalingo lets you create alerts based on an application metric. When the metric's value goes above
-or below a user-defined limit, Scalingo sends a notification on some specified notifiers. See [this
-page]({% post_url platform/app/2000-01-01-notification %}) for more information about the notifiers.
-
-An alert can be added to an application by going to the Settings tab and Alerts sub-menu. 
-
-## Alert Parameters
-
-In order to create a new alert, a few parameters must be provided:
-
-- Container type: can be any container type of an application (e.g. web,
-  clock...).
-- Metric:
-  1. CPU: percentage of CPU consumption
-  1. RAM: percentage of memory consumption
-  1. Swap: percentage of swap consumption
-  1. Response time: 95th percentile of the requests response time
-  1. 5xx errors: amount of HTTP errors (status code ranges from 500 to 599)
-  1. RPM: requests per minute (RPM) received by your application.
-  1. RPM per container: If your application is scaled on multiple containers,
-     the RPM per container divides the RPM of the application by the amount of
-     containers.
-- Limit: any float value.
-- Send when below: send the alert when metric value is _below_ the limit.
-- Notifiers: list of [notifiers]({% post_url
-  platform/app/2000-01-01-notification %}) the alert send a notification to.
-- Duration before trigger: send the alert when metric value is above the limit
-  for the specified duration. For example, specifying 4 minutes means that the
-  alert will be triggered if the limit is reached for 4 consecutive minutes.
-
-## Monitoring alert events
+Scalingo lets you create alerts based on an [application metric][metrics].
+When the metric's value matches a configured condition for a selected duration,
+Scalingo sends a notification to selected [app notifiers][notifiers].
+
+## Creating Alerts
+
+### From the Dashboard
+
+- From your web browser, open your Scalingo dashboard.
+- Select the app for which you want to create an alert.
+- Click the **Settings** tab.
+- In the settings menu, select **Alerts**.
+- Click **Add**.
+- Configure the trigger conditions, including the container type, metric, limit,
+  comparison, and duration before trigger.
+- Select the notifier(s) to use when the alert is triggered.
+- Click **Finish**.
+
+### Alert Requirements
+
+An alert requires at least one notifier and a trigger condition:
+
+Container type
+: Can be any container type of an application (e.g. `web`, `clock`...).
+
+Metric
+: - CPU: percentage of CPU consumption
+  - RAM: percentage of memory consumption
+  - Swap: percentage of swap consumption
+  - Response time: 95th percentile of the requests response time
+  - 5xx errors: amount of HTTP errors (status code ranges from 500 to 599)
+  - RPM: requests per minute (RPM) received by your application.
+  - RPM per container: If your application is scaled on multiple containers,
+    the RPM per container divides the RPM of the application by the amount of
+    containers.
+
+Limit
+: Any float value.
+
+Comparison
+: Send the alert when the metric value is above or below the limit.
+
+Notifiers
+: List of [app notifiers][notifiers] the alert sends a notification to.
+
+Duration before trigger
+: Send the alert when the metric value matches the configured condition for the
+  specified duration. For example, specifying 4 minutes means that the alert
+  is triggered if the condition is matched for 4 consecutive minutes.
+
+## Sending alert notifications
+
+Alerts use the same [notifiers] as application events. An alert must use at least
+one notifier. Each app has a default notifier.
+
+For more information, please visit the page dedicated to [app notifiers][notifiers].
+
+## Alert Events
 
 Every time an alert is triggered, an event is created. This event appears on the application's
-Activity. The user responsible for the operation is labeled `scalingo-platform`. An event is also generated when an alert is created or deleted.
+Activity. The user responsible for the operation is labeled `scalingo-platform`.
+
+The alert-related event types are:
+
+| Event Type            | Display Name    | Description                  |
+| --------------------- | --------------- | ---------------------------- |
+| `alert_added`         | Alert Added     | An alert has been configured |
+| `alert_deleted`       | Alert Deleted   | An alert has been deleted    |
+| `app_alert_triggered` | Alert triggered | An alert was triggered       |
+
+[notifiers]: {% post_url platform/app/2000-01-01-notifiers %}
+[metrics]: {% post_url platform/app/2000-01-01-metrics %}

src/_posts/platform/app/2000-01-01-crash.md

@@ -213,6 +213,6 @@ a recurrent crash occurs (i.e. when an early Runtime Error keeps occuring, or
 when a Timeout Error occurs).
 
 You can modify this behavior by tweaking your
-[Notifier's configuration]({% post_url platform/app/2000-01-01-notification %}).
-The `app_crashed`, `app_crashed_repeated` and the `app_deploy` events can be
-particularily worth considering.
+[app notifier configuration]({% post_url platform/app/2000-01-01-notifiers %}).
+The `app_crashed`, `app_crashed_repeated` and the `app_deployed` events can be
+particularly worth considering.

src/_posts/platform/app/2000-01-01-metrics.md

@@ -3,6 +3,7 @@ title: Application Metrics
 nav: Metrics
 modified_at: 2026-01-02 12:00:00
 tags: app metrics
+index: 35
 ---
 
 Performance metrics of applications hosted on Scalingo are gathered and
@@ -38,7 +39,8 @@ A lot of events are available on the application timeline but only a few relevan
 - Deploy event
 - Scale event
 
-A complete list of events is available in our [developers' documentation](https://developers.scalingo.com/events).
+A complete list of events is available in the [App Notifiers][notifiers]
+documentation.
 
 The **Response time** represents the duration between the time a request arrives
 at our front servers and the time our front servers receives a response from
@@ -130,4 +132,5 @@ type). It can greatly help to spot a bugged container and therefore simplify the
 debugging process.
 
 
+[notifiers]: {% post_url platform/app/2000-01-01-notifiers %}
 [routing-errors]: {% post_url platform/networking/public/2000-01-01-routing %}#http-errors