Understanding Red Hat Lightspeed (Insights) Events and Notifications in the Hybrid Cloud Console
Introduction
The This content is not included.Red Hat Hybrid Cloud Console offers a centralized notifications platform that helps monitor and manage events and alerts from Red Hat Lightspeed (Insights) services. This article explains how events are generated, processed, and delivered, focusing on RHEL-related Lightspeed (Insights) services.
You will learn how to differentiate between event types, delivery channels, and configuration options - enabling you to integrate notifications effectively into your workflows for proactive system health, security, compliance, and performance monitoring.
Note: This article currently covers only RHEL Lightspeed (Insights) and Subscription services and may not apply to non-RHEL services.
Overview of Notifications in the Red Hat Hybrid Cloud Console
How notifications work
The notifications service in the Red Hat Hybrid Cloud Console acts as a centralized platform for delivering alerts and events from various Red Hat Lightspeed (Insights) applications. Each application triggers events based on specific conditions, which are then processed and sent to users or third-party applications through the configured delivery methods.
Events can be system-based (affect individual systems) or account-based (impact multiple systems within an account):
- System-based events: Triggered by conditions affecting individual systems. For example, a compliance policy violation detection on a specific server.
- Account-based events: Affect the entire account rather than a single system. For example, a notification about a vulnerability impacting multiple systems within an account.
Delivery methods
- Users and third-party applications can receive notifications through multiple channels, including:
- User interface (UI): Events appear in the console’s Settings > Notifications > Event Log.
- Email: Instant alerts or daily summaries configured by user preferences.
- Communication tools: Messages in Slack, Google Chat or Microsoft Teams.
- Third-party integrations: Notifications can be forwarded to services such as PagerDuty, ServiceNow, Splunk, Event-Driven Ansible, or custom applications via webhooks.
Tip: You can mix delivery methods. For example, receive critical vulnerabilities via email and forward compliance events to ServiceNow.
Event Matrix: Detailed Event List for Red Hat Lightspeed (Insights) for RHEL
The following table lists events from different Red Hat Lightspeed (Insights) applications, providing details on their scope, trigger conditions, and frequency.
| Application / Service | Event Type / Name | Event Scope (System/Account) | Trigger Condition | Delivery Behavior / Frequency | Notes |
|---|---|---|---|---|---|
| Advisor | Resolved recommendation | System-Based | Triggers when a system checks in and a recommendation is found to be solved. | Once per system when the recommendation is resolved. | |
| Advisor | New recommendation | System-Based | Triggers when a system registers or checks in and a recommendation is detected. | Once per system at first detection. | A brand new recommendation will be generated for the system the next time it checks in and its data is analyzed. |
| Advisor | Deactivated recommendation | Account-Based | Triggers when the recommendation is removed from HCC. | Once per account when the recommendation is deactivated. | |
| Compliance | Policy report failed to upload | System-Based | Triggers when the payload is rejected by HCC/Lightspeed. | Once per system when the compliance payload cannot be ingested or processed. | Possible reasons for failure are discussed in this Knowledgebase Solution article. |
| Compliance | System is non compliant to SCAP policy | System-Based | Triggers when a system is discovered as non-compliant (below the configured compliance threshold). | Once per system when the non-compliance is discovered. | Requires compliance configuration on the system and Compliance policy assignment in Red Hat Lightspeed (Insights). Compliance threshold can also be configured. Only triggers when a system is first discovered as non-compliant to a given compliance profile. If the system becomes compliant and later becomes non-compliant again, the event is not re-triggered. Similarly, if the system is removed from the profile and re-added later, the non-compliant event does not trigger again. Important: This behavior may impact the visibility of recurring non-compliance in automated workflows or monitoring setups. |
| Inventory | Validation error | System-Based | Triggers when the payload is rejected by Red Hat Lightspeed (Insights). | Once per system when the insights-client payload cannot be ingested or processed. | Possible reasons for failure include corrupted data, incorrect values, or another issue. See inventory product documentation for additional details. |
| Inventory | System became stale | System-Based | Triggers when the system’s state changes to stale. | Once per system when its state changes to stale. HCC/Lightspeed triggers these events every hour. | |
| Inventory | System deleted | System-Based | Triggers when a system is deleted from inventory. | Once per system when it gets deleted, either manually or automatically. | |
| Inventory | New system registered | System-Based | Triggers when a system is registered or gets added to the inventory. | Once per system when a new system is added to inventory. | This event triggers regardless of the collector (e.g. insights-client, satellite, subscription manager). |
| Malware | Detected malware | System-Based | Triggers when a new malware is detected. | Once per system when malware is discovered. | Requires malware configuration on the system. |
| Patch | New advisory | Account-Based | Triggers when a system is found with an advisory in the account. | Once per account when the advisory is found. | Important: This event only triggers once per account. It is sent again if all affected systems are fixed and a new system is found with the advisory. Important: This behavior may impact the visibility of recurring advisories in automated workflows or monitoring setups. |
| Resource Optimization | New suggestion | System-Based | Triggers when a system checks in and a suggestion is found. | Once per system when the suggestion is discovered. | To collect and upload data, Performance Co-Pilot (PCP) must be set up on the system with insights-client. Although insights-client runs daily, the first event usually appears after the second upload, about 24 hours after the first. After that, events trigger with each new upload. For details, see the Resource Optimization This content is not included.product documentation. |
| Tasks | Job failed | Job-Based | Triggers when the job encounters an error and cannot complete successfully. | Once when a job fails. | |
| Tasks | Task started | Task-Based | Triggers when a task is initiated by the user or system. | Once when a task starts. | |
| Tasks | Task job completed | Job-Based | Triggers when a job finishes successfully without errors. | Once when a job finishes. | |
| Tasks | Task job started | Job-Based | Triggers when a task job begins execution within the broader task context. | Once when a task job begins. | |
| Tasks | Task cancelled | Task-Based | Triggers when a user or system cancels the task before completion. | Once when cancellation occurs. | |
| Tasks | Executed task completed | Task-Based | Triggers when a task completes execution, including all task jobs. | Once after successful task execution. | |
| Tasks | Task job cancelled | Job-Based | Triggers when a job is manually or automatically cancelled during execution. | Once when a job is cancelled. | |
| Vulnerability | New vulnerability containing security rule | Account-Based | Triggers when a system is found with a critical CVE containing a security rule. | Once per account when the vulnerability is found. | Important: This event only triggers once per account. It is not sent again if all affected systems are fixed and a new system is found with the vulnerability. Important: This behavior may impact the visibility of recurring vulnerabilities in automated workflows or monitoring setups. |
| Vulnerability | Vulnerability with known exploit identified | Account-Based | Triggers when a system is found with a CVE with known exploit. | Once per account when the vulnerability is found. | Important: This event only triggers once per account. It is not sent again if all affected systems are fixed and a new system is found with the vulnerability. Important: This behavior may impact the visibility of recurring vulnerabilities in automated workflows or monitoring setups. |
| Vulnerability | New vulnerability with critical severity | Account-Based | Triggers when a system is found with a critical CVE. | Once per account when the vulnerability is found. | Important: This event only triggers once per account. It is not sent again if all affected systems are fixed and a new system is found with the vulnerability. Important: This behavior may impact the visibility of recurring vulnerabilities in automated workflows or monitoring setups. |
| Vulnerability | New vulnerability with CVSS >= 7.0 | Account-Based | Triggers when a system is found with a CVE with CVSS >= 7.0. | Once per account when the vulnerability is found. | Important: This event only triggers once per account. It is not sent again if all affected systems are fixed and a new system is found with the vulnerability. Important: This behavior may impact the visibility of recurring vulnerabilities in automated workflows or monitoring setups. |
Event Matrix: Detailed Event List for Subscription Services
The following table lists events from the Errata service, providing details on their scope, trigger conditions, and frequency.
| Application / Service | Event Type / Name | Event Scope (System/Account) | Trigger Condition | Delivery Behavior / Frequency | Notes |
|---|---|---|---|---|---|
| Errata | Subscription Bug Fixes | Account-based | Triggers when a new Red Hat Bug Advisory (RHBA) is discovered on the account. | Once per account when the RHBA is discovered. | Important: This event only triggers once per account. Errata notifications are based on subscriptions on the account. |
| Errata | Subscription Enhancements | Account-based | Triggers when a new Red Hat Enhancement Advisory (RHEA) is discovered on the account. | Once per account when the RHEA is discovered. | Important: This event only triggers once per account. Errata notifications are based on subscriptions on the account. |
| Errata | Subscription Security Updates | Account-based | Triggers when a new Red Hat Security Advisory (RHSA) is discovered on the account. | Once per account when the RHSA is discovered. | Important: This event only triggers once per account. Errata notifications are based on subscriptions on the account. |
Manage Red Hat Lightspeed (Insights) Notifications
To configure notifications in the Hybrid Cloud Console, refer to the following product documentation:
- Configuring notifications on the Red Hat Hybrid Cloud Console
- Configuring user preferences for email notifications
- Troubleshooting notification failures
- Integrating the Red Hat Hybrid Cloud Console with third-party applications
- Troubleshooting Hybrid Cloud Console integrations
Frequently Asked Questions
- Why don’t I get a notification every time a system becomes non-compliant again?
Currently, Red Hat Lightspeed (Insights) does not re-trigger certain events for recurring issues on the same system. For example, a system that becomes non-compliant, then compliant, and later becomes non-compliant again will not generate another notification.
See the Compliance section above for more details and available workaround below.
| Event Type | Triggered Per | Re-triggers if issue reoccurs? | Notes |
|---|---|---|---|
| System-based (e.g., Compliance, Advisor) | System | Not automatically | Can sometimes be reset via re-registration. |
| Account-based (e.g., Vulnerability, Patch) | Account | Not automatically | New advisories event only re-triggers if all affected systems are resolved and a new system becomes affected. New vulnerability events never re-trigger on the account. |
| Task/Job events | Task/Job | Yes, per execution | Each new job or task triggers a new event |
| Inventory events | System | Yes, per state change | E.g. stale -> fresh -> stale |
-
Can I force repeat notifications if the same issue happens again later?
In most cases, account-based notifications will not be re-triggered unless all affected systems are resolved and a newly affected system is identified.
For system-based notifications, you may be able to reset the state by unregistering and re-registering the system with Red Hat Lightspeed (Insights), which can retrigger certain events.
Note: this is a workaround and may not apply to all event types. -
What determines the frequency of event notifications: check-in interval or event type?
Most system-based events are triggered based on the scheduled check-in of the system (typically via insights-client), which runs daily by default.
Account-based events, on the other hand, are based on aggregated data refresh intervals, which depend on backend processing within the Hybrid Cloud Console. -
Do I need to manually configure each integration (e.g. Slack, PagerDuty, ServiceNow)?
Yes. Each integration must be configured once per account, following the instructions in the Integrating the Red Hat Hybrid Cloud Console with third-party applications product documentation.
As part of the configuration wizard, you can optionally assign the integration to specific notifications. You can also configure this later using behavior groups, which define how and where events are delivered.
See Configuring notifications on the Red Hat Hybrid Cloud Console product documentation. -
Can I filter or prioritize events (e.g. only receive critical vulnerabilities)?
At this time, filtering is limited. While event types inherently categorize notifications (e.g. Critical CVEs vs general vulnerabilities), the platform does not yet support custom filtering rules at the notification level.
For advanced filtering or prioritization, consider using third-party tools like Event-Driven Ansible, Splunk, or ServiceNow, where rules and workflows can be customized based on event payloads. -
Can I test whether notifications are working properly?
Yes. You can test each integration individually using the ‘Test’ action, which sends a sample payload to your target application or service.
See Integrating the Red Hat Hybrid Cloud Console with third-party applications product documentation for more details. -
What happens if an integration fails?
If a notification delivery fails (e.g. due to authentication errors, misconfigured endpoints, or integration downtime), the event is logged but not automatically retried.
If multiple delivery failures occur consecutively, the integration may be automatically disabled to prevent further errors. In such cases, users must manually re-enable the integration from the Integrations configuration page.
You can review failed deliveries and troubleshoot issues in the Notification history (Event Log) and Integration status sections of the Hybrid Cloud Console.
Conclusion
By understanding how Red Hat Lightspeed (Insights) generates and delivers events, administrators can tailor their workflows for efficient monitoring and proactive management. Use this article as a reference to configure notifications, troubleshoot delivery issues, and integrate Red Hat Lightspeed (Insights) events into third-party tools.
For additional configuration and integration resources, explore the Red Hat Hybrid Cloud Console and Red Hat Lightspeed (Insights) documentation, and related the Red Hat Knowledgebase article.