Acknowledged date for a repeating alert condition still shows the original acknowledged date
We've been seeing an issue where we get a critical alert, we are notified through our escalation chains, and we acknowledge the alert. However, the action we take to resolve the alert is only enoughdrop the severity on the alert to error or warning, not clear it entirely. If that alert crosses a critical threshold again it will show up as acknowledged from the first time it went critical, which will prevent all notification. For example we have threshold for percent used on a volume at >=90 95 98. The volume hits 98%, we are notified and ack the alert, but are only able to clear space to drop the volume down to 92%. If that volume hits 98% again it will show up as already acknowledged and prevents all notifications (see below): This is the expected behavioraccording to LM, but I don't see a benefit in this behavior and it seems risky if you expect to get alerted any time a threshold is crossed. We'd like to be able to receive anotification any time an alert crosses an threshold, regardless if it has been acknowledged at a higher severity for that alert "instance."2Views0likes7CommentsAdd option to disable email reply commands
Please add an option to disable the "reply commands" footer section in notification emails. We want our users to follow our organisationalprocess and procedure. You may reply to this alert with these commands: - ACK (comment) - acknowledge alert - NEXT - escalate to next contact - SDT X - schedule downtime for this alert on this host for X hours. - SDT datasource X - SDT for all instances of the datasource on this host for X hours - SDT host X - SDT for entire host for X hours2Views1like2CommentsLine separate GROUP token in notification emails
At the moment the ##GROUP## token appears as below in emails. This is very difficult to read as the comma indicating a separate group is hard to spot. Can you please split the ##GROUP## token on the comma and put each one on a new line. Infrastructure Services/Primary/Americas/Network Services/Network Services - Corporate - US/Routers/CenturyLink, Infrastructure Services/Primary/Americas/Network Services/Network Services - Corporate - US/# Locations/Orlando3Views1like0CommentsUnlink Alert page permission from the alert aknowlwedgement URL
Currently the hyperlink in an alert notification email requires that users have permission to view the all Alerts view. We don't want users to have access to this view. Please make it so that the notification hyperlink to ack an alert works without the need for this permission.0Views0likes0CommentsAbility to customize web service alert emails
With DataSources and EventSources it is possible to tailor the alert message and content of the alert emails. However, with web services there is only the one template. We need to be able to tailor the email content on a web service by web service basis. Please make it possible to configure the alert email content per service check. Ideally it should be possible to define as many message templates as we like, and then choose which template to apply at a service group level, so that the service check objects inherit the template from the parent service group.4Views0likes2CommentsConfigurable sender address
Hi, Currently we are servicing multiple customers though LM and want to expand this service to more customers. In this ambition we face one huge challange. Our ITSM contains mission critical and detailed information on our customer systems. Because of this we are not allowed (and not willing) to open this system up for the internet and enable for LM HTTP integrations. This means we can only use email as a save interface between LM monitored systems and our ITSM. Mission critical systems are monitored by on-premise monitoring and notify us using unique sender adresses. This allows us to automatically differentiate between various customers and group/organize tickets accordingly. Sadly all notification send by LM have a fixed sender adress. Because the same sender adress is used for all customer notifications, our ITSM tooling isnt able to differentiate between various customers. All notifications are reported from: alerter@#CUSTOMER#.logicmonitor.com. Therefore we would like to request the ability to differentiate sender adresses from the escalation chain level. For example customer1.alerter@#CUSTOMER#.logicmonitor.com. customer2.alerter@#CUSTOMER#.logicmonitor.com. This additional field should be easy enough to filter out concerning actionable emails regex: ^.*alerter@(.+)\..+$ but will allow us to differentiate these tickets to various customer groups. This will then enable us to report about these notifications in our SLA reports accordingly, assign them to the right systems automatically, assign them to the right engineers automatically....... making our lives much easier ;-) I really hope this can be addressed quickly. sidenote: SSO might also be called a welcome feature, now i hold three accounts ;-)4Views0likes4Comments