OpenNMS · Bonrob2 · Jul 10, 2023 · Jul 6, 2023 · Jul 7, 2023 · Jul 7, 2023
diff --git a/docs/modules/ROOT/pages/index.adoc b/docs/modules/ROOT/pages/index.adoc
@@ -1,6 +1,7 @@
 
 [[welcome]]
 = Welcome to the {page-component-title} Documentation
+:description: Overview of OpenNMS Horizon/Meridian documentation including product architecture diagram and how to navigate the documentation.
 
 [options="autowidth"]
 |===

diff --git a/docs/modules/operation/pages/deep-dive/introduction.adoc b/docs/modules/operation/pages/deep-dive/introduction.adoc
@@ -1,2 +1,5 @@
 
-= Deep Dive
+= Deep Dive
+:description: Overview of deep-dive section that provides in-depth procedures on OpenNMS Horizon/Meridian tasks and features.
+
+This section provides in-depth procedures on many {page-component-title} tasks and features.
diff --git a/docs/modules/operation/pages/deep-dive/provisioning/adapters.adoc b/docs/modules/operation/pages/deep-dive/provisioning/adapters.adoc
@@ -1,5 +1,6 @@
 [[adapters]]
 = Adapters
+:description: Overview of provisioning adapters in OpenNMS Horizon/Meridian to integrate with external systems during inventory import.
 
 The {page-component-title} Provisiond API supports provisioning adapters (plugins) for integration with external systems during the provisioning import phase.
 These adapters let OpenNMS exchange data with other systems, allowing the enrichment of node data.

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/auto-discovery.adoc b/docs/modules/operation/pages/deep-dive/provisioning/auto-discovery.adoc
@@ -1,6 +1,7 @@
 
 [[auto-discovery]]
 = Auto Discovery
+:description: How to automatically add nodes to OpenNMS Horizon/Meridian through discovery scans.
 
 Auto discovery is the process of automatically adding nodes to {page-component-title}.
 This is done through discovery, which is run either periodically on a schedule or as one-off, unscheduled operations.

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/configuration.adoc b/docs/modules/operation/pages/deep-dive/provisioning/configuration.adoc
@@ -1,6 +1,7 @@
 
 [[beyond-quick-start]]
 = Configuration Options
+:description: Overview of inventory provisioning configuration options in OpenNMS Horizon/Meridian with cross-reference to quick start inventory section.
 
 The xref:operation:quick-start/inventory.adoc[Provision Inventory] Quick Start section provides an overview and basic procedures to start provisioning using the default configuration.
 

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/detectors.adoc b/docs/modules/operation/pages/deep-dive/provisioning/detectors.adoc
@@ -1,5 +1,6 @@
 [[ga-detectors]]
 = Detectors
+:description: Overview of detectors in OpenNMS Horizon/Meridian to detect available services on nodes automatically. Introduction to metadata domain-specific language.
 
 Use detectors within the provisioning process to detect available services on nodes automatically.
 

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/directed-discovery.adoc b/docs/modules/operation/pages/deep-dive/provisioning/directed-discovery.adoc
@@ -1,6 +1,7 @@
 
 [[directed-discovery]]
 = Directed Discovery
+:description: How to manually add nodes to OpenNMS Horizon/Meridian through the requisition UI, through the REST API, and via newSuspect events.
 
 Directed discovery is the process of manually adding nodes to {page-component-title} through the requisition UI.
 

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/fine-grained.adoc b/docs/modules/operation/pages/deep-dive/provisioning/fine-grained.adoc
@@ -1,4 +1,5 @@
 = Fine-Grained provisioning using provision.pl
+:description: How to use the provision.pl script for fine-grained provisioning in OpenNMS Horizon/Meridian.
 
 `provision.pl` provides an example command-line interface to the provisioning-related {page-component-title} REST API endpoints.
 

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/foreign-source.adoc b/docs/modules/operation/pages/deep-dive/provisioning/foreign-source.adoc
@@ -1,6 +1,7 @@
 
 [[foreign-source-definition]]
 = Foreign Source Definition
+:description: Use the foreign source definition in OpenNMS Horizon/Meridian to define detection services(DNS, FTP, ICMP, etc.), set scan interval. and create a policy.
 
 The default foreign source definition serves as a template that defines the services to detect on (DNS, FTP, ICMP, and so on), the scan interval for discovery, and the policies to use when provisioning.
 Policies determine entity persistence and set attributes on the discovered entities that control {page-component-title} management behavior.

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/import-handler.adoc b/docs/modules/operation/pages/deep-dive/provisioning/import-handler.adoc
@@ -1,6 +1,7 @@
 
 [[import-handlers]]
 = Import Handlers
+:description: Overview of import handlers in OpenNMS Horizon/Meridian to facilitate provisioning nodes from an external system into a requisition.
 
 {page-component-title} supports a number of import handlers to facilitate provisioning nodes from an external system (foreign source) into a requisition.
 

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/integration.adoc b/docs/modules/operation/pages/deep-dive/provisioning/integration.adoc
@@ -1,6 +1,7 @@
 
 [[provisiond-integration]]
 = Integrating with Provisiond
+:description: How to use the provision daemon (provisiond) to integrate inventory systems in OpenNMS Horizon/Meridian.
 
 If you have another inventory system to keep track of nodes on your network, you can define a requisition to group nodes within {page-component-title}.
 There are multiple ways you can add nodes to a requisition.

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/introduction.adoc b/docs/modules/operation/pages/deep-dive/provisioning/introduction.adoc
@@ -1,6 +1,7 @@
 
 [[ga-provisioning-introduction]]
 = Provisioning
+:description: Overview of inventory provisioning in OpenNMS Horizon/Meridian: automatic and directed discovery, and node asset import.
 
 Provisioning is a process that imports node and service definitions either from an external source, such as DNS or HTTP, or via the {page-component-title} web UI.
 The Provisiond daemon maintains your managed entity inventory through policy-based provisioning.

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/meta-data.adoc b/docs/modules/operation/pages/deep-dive/provisioning/meta-data.adoc
@@ -1,5 +1,6 @@
 [[ga-provisioning-meta-data]]
 = MetaData assigned to nodes
+:description: How to use arbitrary metadata in requisitions for OpenNMS Horizon/Meridian provisioning.
 
 A requisition can contain arbitrary link:#ga-meta-data[metadata] for each node, interface, and service it contains.
 During provisioning, the metadata is copied to the model and persisted in the database.

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/policies.adoc b/docs/modules/operation/pages/deep-dive/provisioning/policies.adoc
@@ -1,5 +1,6 @@
 [[policies]]
 = Policies
+:description: Overview of policy API in OpenNMS Horizon/Meridian to control persistence of discovered IP and SNMP interface entities.
 
 The Policy API in Provisiond lets you control the persistence of discovered IP and SNMP interface entities and node tags during the scan phase.
 

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/scalability.adoc b/docs/modules/operation/pages/deep-dive/provisioning/scalability.adoc
@@ -1,5 +1,6 @@
 
 = Addressing Scalability
+:description: How to address scalability in OpenNMS Horizon/Meridian: parallelization and non-blocking I/O, policies, auto rescanning, and disabling rescan.
 
 The explosive growth and density of the IT systems being deployed today to support non-traditional IP services impacts management systems like never before, and demands tremendous amounts of scalability.
 The scalability of a management system is defined by its capacity to manage large numbers of entities coupled with its efficiency for managing the entities.

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/snmp-encryption.adoc b/docs/modules/operation/pages/deep-dive/provisioning/snmp-encryption.adoc
@@ -1,4 +1,5 @@
 == Encrypt SNMP credentials
+:description: How to encrypt SNMP credentials in OpenNMS Horizon/Meridian, including Karaf commands.
 
 You can save SNMP credentials like readCommunity/WriteCommunity and authPassPhrase/privPassPhrase on the file system in encrypted format.
 

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/snmp-profile.adoc b/docs/modules/operation/pages/deep-dive/provisioning/snmp-profile.adoc
@@ -1,4 +1,5 @@
 = SNMP Profiles
+:description: How to use SNMP profiles in OpenNMS Horizon/Meridian to help with provisioning.
 
 SNMP Profiles are prefabricated sets of SNMP configuration that are automatically "fitted" against eligible IP addresses at provisioning time.
 Each profile may have a unique label and an optional filter expression.

diff --git a/docs/modules/operation/pages/deep-dive/provisioning/xml-samples.adoc b/docs/modules/operation/pages/deep-dive/provisioning/xml-samples.adoc
@@ -1,6 +1,7 @@
 
 [[xml-sample-provision]]
 = XML Samples
+:description: Sample XML configuration for provisioning tasks in OpenNMS Horizon/Meridian.
 
 This section provides sample XML configuration for many of the tasks described in the Provisioning chapter.
 

diff --git a/...eep-dive/service-assurance/application-perspective-monitoring/introduction.adoc b/...eep-dive/service-assurance/application-perspective-monitoring/introduction.adoc
@@ -1,5 +1,6 @@
 
 = Application Perspective Monitoring
+:description: Overview of application perspective monitoring in OpenNMS Horizon/Meridian to view availability of remote services from another service.
 
 Application Perspective Monitoring in {page-component-title} lets you see the availability of a remote service.
 For example, the service may be hosted in Houston, but accessed in Seattle from your central location in New York.

diff --git a/docs/modules/operation/pages/deep-dive/service-assurance/configuration.adoc b/docs/modules/operation/pages/deep-dive/service-assurance/configuration.adoc
@@ -1,6 +1,7 @@
 
 [[ga-pollerd-configuration]]
 = Configure Pollerd
+:description: How to configure pollerd in OpenNMS Horizon/Meridian to change service monitoring behavior: define thread pool, downtime model, asynchronous engine.
 
 For information on configuration and log files related to pollerd, see xref:reference:daemons/daemon-config-files/pollerd.adoc[] in the reference section.
 

diff --git a/docs/modules/operation/pages/deep-dive/service-assurance/critical-service.adoc b/docs/modules/operation/pages/deep-dive/service-assurance/critical-service.adoc
@@ -1,6 +1,8 @@
 
 = Improve Monitoring Efficiency
 
+:description: How to improve monitoring in OpenNMS Horizon/Meridian through critical services.
+
 Monitoring services on an IP network can be resource-intensive, especially in cases where many of the services are not available.
 When a service is offline or unreachable, the monitoring system spends most of its time waiting for retries and timeouts.
 To improve efficiency, {page-component-title} deems all services on an interface to be down if the critical service is down.

diff --git a/docs/modules/operation/pages/deep-dive/service-assurance/downtime-model.adoc b/docs/modules/operation/pages/deep-dive/service-assurance/downtime-model.adoc
@@ -1,6 +1,7 @@
 
 [[ga-service-assurance-downtime-model]]
 = Detect Short Service Outages
+:description: How to detect short service outages with OpenNMS Horizon/Meridian using a downtime model to reduce the monitoring interval to every 30 seconds.
 
 By default, the monitoring interval for a service is five minutes.
 You can use the configurable downtime model to detect short service outages, like those caused by automatic network rerouting.

diff --git a/docs/modules/operation/pages/deep-dive/service-assurance/introduction.adoc b/docs/modules/operation/pages/deep-dive/service-assurance/introduction.adoc
@@ -1,6 +1,7 @@
 
 [[ga-service-assurance]]
 = Service Assurance
+:description: Overview of how OpenNMS Horizon/Meridian test availability of services and devices and their latency through service monitors.
 
 This section describes how {page-component-title} tests the availability of a service or device and measures its latency.
 In {page-component-title}, a service monitor framework fulfills these tasks.

diff --git a/docs/modules/operation/pages/deep-dive/service-assurance/path-outages.adoc b/docs/modules/operation/pages/deep-dive/service-assurance/path-outages.adoc
@@ -1,6 +1,7 @@
 
 [[ga-service-assurance-path-outage]]
 = Use Path Outages to Suppress Notifications
+:description: How to use path outages to suppress notifications with OpenNMS Horizon/Meridian.
 
 An outage on a central network component can cause a large number of node outages.
 You can use path outages to suppress notifications based on how nodes depend on each other in the network, as outlined in a critical path definition.

diff --git a/docs/modules/operation/pages/deep-dive/service-assurance/polling-packages.adoc b/docs/modules/operation/pages/deep-dive/service-assurance/polling-packages.adoc
@@ -1,6 +1,7 @@
 
 [[ga-pollerd-packages]]
 = Poller Packages
+:description: How to group service configurations into polling packages to define more complex monitoring configurations with OpenNMS Horizon/Meridian.
 
 You can group service configurations into polling packages to define more complex monitoring configurations.
 This allows you to assign different service configurations to nodes.

diff --git a/docs/modules/operation/pages/deep-dive/service-assurance/scheduled-outages.adoc b/docs/modules/operation/pages/deep-dive/service-assurance/scheduled-outages.adoc
@@ -1,5 +1,6 @@
 
 = Scheduled Outages
+:description: How to define scheduled outages to suppress notifications with OpenNMS Horizon/Meridian, and how to schedule an outage for a node.
 
 Scheduled outages let you suppress notifications and pause status polling, threshold checking, and data collection during a specified time period.
 You might want to schedule an outage for any of the following reasons:

diff --git a/docs/modules/operation/pages/deep-dive/service-assurance/service-monitors.adoc b/docs/modules/operation/pages/deep-dive/service-assurance/service-monitors.adoc
@@ -1,5 +1,6 @@
 
 = Service Monitors
+:description: Overview of how service monitors work with OpenNMS Horizon/Meridian.
 
 The pollerd service uses service monitors to check the status of services running on nodes.
 These monitors will track if services are up or down, and will generate outages if the desired service state is not met.

diff --git a/docs/modules/operation/pages/deep-dive/service-assurance/shell/introduction.adoc b/docs/modules/operation/pages/deep-dive/service-assurance/shell/introduction.adoc
@@ -1,5 +1,6 @@
 
 = Shell Commands
+:description: Overview of Karaf shell commands to help administer and diagnose issues related to service assurance with OpenNMS Horizon/Meridian.
 
 A number of Karaf Shell commands are available to help administer and diagnose issues related to service assurance.
 

diff --git a/...modules/operation/pages/deep-dive/service-assurance/shell/pollerd-schedule.adoc b/...modules/operation/pages/deep-dive/service-assurance/shell/pollerd-schedule.adoc
@@ -1,8 +1,9 @@
 
 [[ga-service-assurance-schedule-shell]]
 = Pollerd Schedule
+:description: Karaf shell command to output details of the Pollerd scheduler in OpenNMS Horizon/Meridian.
 
-The `opennms:pollerd-schedule` Karaf Shell command can be used to output details of the Pollerd scheduler.
+You can use the `opennms:pollerd-schedule` Karaf Shell command to output details of the Pollerd scheduler.
 
 * List all collected statistics of the Pollerd daemon.
 +

diff --git a/docs/modules/operation/pages/deep-dive/thresholds/datasource.adoc b/docs/modules/operation/pages/deep-dive/thresholds/datasource.adoc
@@ -1,5 +1,6 @@
 
 = Thresholding Tasks
+:description: Thresholding tasks in OpenNMS Horizon/Meridian: use metadata, confirm you are collecting metrics, and determine the data source.
 
 For information on how to create a basic or expression-based threshold, see xref:quick-start/thresholding.adoc[] in the Quick Start section.
 This section describes related thresholding tasks.

diff --git a/docs/modules/operation/pages/deep-dive/thresholds/thresh-group.adoc b/docs/modules/operation/pages/deep-dive/thresholds/thresh-group.adoc
@@ -1,6 +1,7 @@
 
 [[threshold-group]]
 = Create a Threshold Group
+:description: How to create a threshold group in OpenNMS Horizon/Meridian to associate a set of thresholds to a service. Includes list of default threshold groups.
 
 A threshold group associates a set of thresholds to a service (for example, thresholds that apply to all Cisco devices).
 {page-component-title} includes the following preconfigured, editable threshold groups:

diff --git a/docs/modules/operation/pages/deep-dive/thresholds/thresh-service.adoc b/docs/modules/operation/pages/deep-dive/thresholds/thresh-service.adoc
@@ -1,5 +1,6 @@
 
 = Thresholding Service
+:description: Overview of thresholding service in OpenNMS Horizon/Meridian to maintain the state of the performance metrics. Distributed thresholding with Sentinel.
 
 The Thresholding Service maintains the state of the performance metrics and generates alarms when thresholds are triggered (armed) or cleared (unarmed).
 The service listens for and compares performance metrics after they are persisted to the time series database.

diff --git a/docs/modules/operation/pages/deep-dive/thresholds/thresholding.adoc b/docs/modules/operation/pages/deep-dive/thresholds/thresholding.adoc
@@ -1,5 +1,6 @@
 
 = Thresholding
+:description: Overview of thresholding in OpenNMS Horizon/Meridian to define limits against a managed entity's performance metrics.
 
 A threshold lets you define limits against a managed entity's network performance metrics.
 When a value goes above or below the specified limit, an event is triggered.

diff --git a/docs/modules/operation/pages/deep-dive/thresholds/troubleshoot.adoc b/docs/modules/operation/pages/deep-dive/thresholds/troubleshoot.adoc
@@ -1,6 +1,7 @@
 
 [[troubleshoot-thresholds]]
 = Troubleshoot and Manage Thresholds
+:description: Troubleshoot and manage thresholds in OpenNMS Horizon/Meridian: enumerate persisted threshold states, display state details, and clear persisted states.
 
 This section includes shell commands that can help to debug and manage thresholding.
 

diff --git a/docs/modules/operation/pages/deep-dive/user-management/pre-authentication.adoc b/docs/modules/operation/pages/deep-dive/user-management/pre-authentication.adoc
@@ -1,5 +1,6 @@
 
 = Web UI Pre-Authentication
+:description: How to run OpenNMS Horizon/Meridian behind a proxy that provides pre-authentication.
 
 You can configure your {page-component-title} instance to run behind a proxy that provides authentication.
 Authenticated users can then be directed to the {page-component-title} web UI using a header.

diff --git a/docs/modules/operation/pages/deep-dive/user-management/security-roles.adoc b/docs/modules/operation/pages/deep-dive/user-management/security-roles.adoc
@@ -1,6 +1,7 @@
 
 [[ga-role-user-management-roles]]
 = Assign User Permissions
+:description: How to assign user permissions in OpenNMS Horizon/Meridian: default security roles (admin, RTC, asset editor, etc.) and creating custom security roles.
 
 You can control user permission levels by creating and assigning security roles.
 These roles regulate access to the {page-component-title} web UI and the REST API to exchange monitoring and inventory information.

diff --git a/docs/modules/operation/pages/deep-dive/user-management/user-config.adoc b/docs/modules/operation/pages/deep-dive/user-management/user-config.adoc
@@ -1,6 +1,8 @@
 
 [[ga-user-config]]
 = User Creation and Configuration
+:description: How to create users and user schedules in OpenNMS Horizon/Meridian.
+
 
 Only a user with admin privileges can create users and assign security roles.
 We recommend creating a new user with admin privileges instead of using the default `admin` user profile (see <<quick-start/users.adoc#ga-admin-user-setup, Admin user setup>>).

diff --git a/docs/modules/operation/pages/deep-dive/user-management/user-groups.adoc b/docs/modules/operation/pages/deep-dive/user-management/user-groups.adoc
@@ -1,6 +1,7 @@
 
 [[ga-user-groups]]
 = Groups
+:description: How to create user groups and add members to them in OpenNMS Horizon/Meridian.
 
 Groups in {page-component-title} are collections of users.
 They may be used to organize users, such as in the case of an instance with many users or permissions sets.

diff --git a/docs/modules/operation/pages/deep-dive/user-management/user-maintenance.adoc b/docs/modules/operation/pages/deep-dive/user-management/user-maintenance.adoc
@@ -1,6 +1,7 @@
 
 [[ga-user-maintenance]]
 = User Maintenance
+:description: User maintenance in OpenNMS Horizon/Meridian: changing passwords, deletion, advanced configuration in users.xml.
 
 Users are entities with login accounts in the {page-component-title} system.
 Ideally, each user account corresponds to only one person.

diff --git a/docs/modules/operation/pages/deep-dive/user-management/user-oncall.adoc b/docs/modules/operation/pages/deep-dive/user-management/user-oncall.adoc
@@ -1,5 +1,6 @@
 
 = On-Call Roles
+:description: How to create on-call roles in OpenNMS Horizon/Meridian and assign pre-defined duty schedules to groups of users.
 
 On-call roles let you assign a predefined <<deep-dive/user-management/user-config.adoc#ga-user-schedule, duty schedule>> to an existing group of users.
 A common use case is to have system engineers in on-call rotations with a defined schedule.

diff --git a/docs/modules/operation/pages/overview/overview.adoc b/docs/modules/operation/pages/overview/overview.adoc
@@ -1,6 +1,7 @@
 
 [[overview]]
 = Overview
+:description: Overview of the operation section for the OpenNMS Horizon/Meridian documentation, which provides information to configure and use the software.
 
 The Operation section provides information and procedures for configuration and use of the {page-component-title} platform.
 The section uses a task-based approach, and the chapters are arranged in the order we recommend to start working with {page-component-title}.

diff --git a/docs/modules/operation/pages/quick-start/baseline.adoc b/docs/modules/operation/pages/quick-start/baseline.adoc
@@ -1,6 +1,8 @@
 
 = Step 6: Establish a Baseline
 
+:description: Step 6 of OpenNMS Horizon/Meridian setup: establish a baseline by determining your environment's "normal".
+
 This section describes how to establish a baseline for your {page-component-title} instance.
 Determining your environment's baseline operating state will help you evaluate how effective your notification rules are, your network's peak operating times, and other useful metrics.
 

diff --git a/docs/modules/operation/pages/quick-start/beyond-qs.adoc b/docs/modules/operation/pages/quick-start/beyond-qs.adoc
@@ -1,5 +1,6 @@
 
 = Beyond the Quick Start Guide
+:description: Additional tasks to customize OpenNMS Horizon/Meridian: manage users, inventory, performance, thresholding, service availability, and notification.
 
 After you finish following the steps in this Quick Start guide, your {page-component-title} instance should be set up and monitoring your network.
 Of course, there is still much more that you can do to customize {page-component-title} to suit your needs.

diff --git a/docs/modules/operation/pages/quick-start/introduction.adoc b/docs/modules/operation/pages/quick-start/introduction.adoc
@@ -1,5 +1,6 @@
 
 = Quick Start
+:description: Overview of OpenNMS Horizon/Meridian quick start documentation.
 
 This Quick Start guide assumes that you have already completed the xref:deployment:core/introduction.adoc[deployment steps], have xref:deployment:core/getting-started.adoc[installed a {page-component-title} instance], and that you are able to connect to the web UI at `\http://<ip-or-fqdn-of-your-server>:8980/opennms`.
 

diff --git a/docs/modules/operation/pages/quick-start/inventory.adoc b/docs/modules/operation/pages/quick-start/inventory.adoc
@@ -1,5 +1,6 @@
 
 = Step 3: Provision Inventory
+:description: Step 3 of OpenNMS Horizon/Meridian setup: configure SNMP for provisioning, create a requisition, and configure a discovery.
 
 {page-component-title} installs with a base configuration that automatically begins service-level monitoring and reporting as soon as you identify and catalog (provision) the managed entities (nodes, IP interfaces, SNMP interfaces, and services) that you want to monitor.
 The default configuration also enables self-monitoring of the OpenNMS service, and discovers a single node with the interface `127.0.0.1` (see xref:deployment:core/getting-started.adoc#first-monitored-node[First monitored node]).

diff --git a/docs/modules/operation/pages/quick-start/notification-config.adoc b/docs/modules/operation/pages/quick-start/notification-config.adoc
@@ -1,5 +1,6 @@
 
 = Step 8: Configure Notifications
+:description: Step 8 of OpenNMS Horizon/Meridian setup: configure event notifications and create filter rules.
 
 This section describes how to configure and customize your {page-component-title} notifications.
 

diff --git a/docs/modules/operation/pages/quick-start/notifications.adoc b/docs/modules/operation/pages/quick-start/notifications.adoc
@@ -1,5 +1,6 @@
 
 = Step 2: Turn on Default Notifications
+:description: Step 2 of OpenNMS Horizon/Meridian setup: turn on default notifications, notification definitions, and configuring destination paths.
 
 This section describes how to turn default notifications on in {page-component-title}.
 

diff --git a/docs/modules/operation/pages/quick-start/performance-data.adoc b/docs/modules/operation/pages/quick-start/performance-data.adoc
@@ -1,5 +1,6 @@
 
 = Step 4: Set Up Performance Data Collection
+:description: Step 4 of OpenNMS Horizon/Meridian setup: set up performance data collection and SNMP collectors and data collection groups.
 
 This section describes performance data collection in {page-component-title}.
 

diff --git a/docs/modules/operation/pages/quick-start/service-assurance.adoc b/docs/modules/operation/pages/quick-start/service-assurance.adoc
@@ -1,5 +1,6 @@
 
 = Step 7: Determine Service Availability
+:description: Step 7 of OpenNMS Horizon/Meridian setup: determine service availability, pollerd, service monitor framework.
 
 By default, {page-component-title} monitors a number of services, including ICMP, DNS, Elasticsearch, SMTP, FTP, SNMP, HTTP(S), SSH, Postgres, IMAP, and POP3.
 

diff --git a/docs/modules/operation/pages/quick-start/thresholding.adoc b/docs/modules/operation/pages/quick-start/thresholding.adoc
@@ -1,5 +1,6 @@
 
 = Step 5: Set up a Threshold
+:description: Step 5 of OpenNMS Horizon/Meridian setup: set up and test a threshold, create and expression-based threshold, and threshold settings.
 
 A threshold defines limits against the network performance metrics (CPU load, bandwidth, disk space, and so on) of a managed entity to trigger an xref:deep-dive/events/introduction.adoc[event] (record) when a datasource value goes above or below the specified limit.
 The threshold types are as follows:

diff --git a/docs/modules/operation/pages/quick-start/users.adoc b/docs/modules/operation/pages/quick-start/users.adoc
@@ -1,5 +1,6 @@
 
 = Step 1: First-Time Sign In
+:description: Step 1 to set up OpenNMS Horizon/Meridian: usage statistics, creating a user, default admin and rtc accounts.
 
 As part of the installation process, we recommend logging in using the default `admin` account.
 If you have not already done so, sign in for the first time, opt in or out of usage statistics data collection, and change the `admin` account password to a secure one (see xref:deployment:core/getting-started.adoc#ga-data-choices[First-time sign in and data choices]).