# Very strange: Icinga2 does not send SMS after downtimes

**URL:** <https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304>\
**Category:** Icinga 2\
**Tags:** downtime, sms\
**Created:** [September 24, 2021, 1:03pm UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304 "2021-09-24T13:03:37Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![queoadmin](https://community.icinga.com/letter_avatar_proxy/v4/letter/q/d07c76/32.png) [@queoadmin](https://community.icinga.com/u/queoadmin)\
**Post date:** [September 24, 2021, 1:03pm UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/1 "2021-09-24T13:03:37Z")

</div>

Hi!

I have a very strange problem…  
We use Icinga2 at office to check many servers. Normally it works without any problem, but sometimes we don’t receive SMS of the problems…

After some tests I got something reproducible: I set a downtime for a service (or an host), then it happens “some shit”. Since there is a downtimes, nothing will be sent. Correct!  
Then the downtime expires (or will deleted). The service is even in critical (or warning) state.  
Now the very strange problem: the E-Mails will be sent, but not the SMS…

We defined two groups of services “high\_prio” (E-Mails and SMS will be sent) and “low\_prio” (only E-Mail will be sent).  
Of course, the problem occours only with “high\_prio” services…

I defined the SMS notification as:

> template Notification “sms-service-notification” {  
> command = “sms-service-notification”
> 
> states = [OK, Warning, Critical]  
> types = [Problem]
> 
> vars += {  
> notification\_from = “Monitoring [icinga@our.domain.com](mailto:icinga@our.domain.com)”  
> notification\_logtosyslog = false  
> }
> 
> period = “24x7”  
> }
> 
> apply Notification “sms-service-notification” to Service {  
> import “sms-service-notification”  
> interval = 0 // disable re-notification
> 
> if (service.vars.notificationgroups != “”) {  
> user\_groups = service.vars.notificationgroups  
> } else {  
> user\_groups = host.vars.notificationgroups  
> }
> 
> assign where service.vars.priority == “high” || (service.vars.priority == null && host.vars.priority == [“high”])  
> }

We defined a user for these SMS as:

> object User “it” {  
> import “generic-user”
> 
> display\_name = “IT”  
> groups = [  
> “icingaadmins”,  
> “admins”,  
> “high-prio”,  
> “low-prio”  
> ]  
> email = “devnull@internal.mail.local”  
> vars.mobile = “handy-admin@internal.mail.local”  
> }

The NotificationCommand `sms-service-notification` just sends an E-Mail to vars.mobile. The Mailserver will then send the data to a GSM-Modem.

So, after my tests, I see, that if the problem occours during a downtime, after the downtime (if the problem persists) just the normal E-Mails will be sent, but `sms-service-notification` will just not be called…

Has someone an explanation for this problem? And maybe a suggestion how to solve it?

Thanks a lot  
Luca

---

<div class="post-metadata">

**Author:** ![steaksauce](https://community.icinga.com/user_avatar/community.icinga.com/steaksauce/32/1831_2.png) [@steaksauce](https://community.icinga.com/u/steaksauce)\
**Post date:** [September 27, 2021, 3:47pm UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/2 "2021-09-27T15:47:05Z")

</div>

We have troubles with SMS in which if we use the “email address” of a phone number to send SMS, the carriers block us and have us blacklisted.

Answer (in our case anyways) is to look at something like Twilio or Pager Duty to send the SMS alerts. We bought time on this by setting up Slack alerts, but I was pushing for Pager Duty.

---

<div class="post-metadata">

**Author:** ![queoadmin](https://community.icinga.com/letter_avatar_proxy/v4/letter/q/d07c76/32.png) [@queoadmin](https://community.icinga.com/u/queoadmin)\
**Post date:** [September 28, 2021, 6:20am UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/3 "2021-09-28T06:20:55Z")

</div>

Hi Ben!

This can **not** be our problem, since our internal mailserver manage the E-Mail and, in case of an “SMS-E-Mail” sends it to a GSM-Modem.  
And I can see in the Logs, that Icinga did not even try to send the “SMS-E-Mail” if the service if in state warning or critical after a downtime. But it sends “normal” E-Mails in this case… Very very strange…

Any other idea?

Thanks  
Luca

---

<div class="post-metadata">

**Author:** ![steaksauce](https://community.icinga.com/user_avatar/community.icinga.com/steaksauce/32/1831_2.png) [@steaksauce](https://community.icinga.com/u/steaksauce)\
**Post date:** [September 28, 2021, 2:28pm UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/4 "2021-09-28T14:28:40Z")

</div>

Out of ideas from my end ☹  
Would be interested to see if this gets resolved though.

---

<div class="post-metadata">

**Author:** ![theFeu](https://community.icinga.com/user_avatar/community.icinga.com/thefeu/32/7277_2.png) [@theFeu](https://community.icinga.com/u/theFeu)\
**Post date:** [September 29, 2021, 9:56am UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/5 "2021-09-29T09:56:42Z")

</div>

We always love to see posts formatted according to the [formatting guidelines](https://community.icinga.com/t/create-topics-and-master-markdown-formatting/69) where you can also find some tips on how to format configuration 🙂

---

<div class="post-metadata">

**Author:** ![bkai](https://community.icinga.com/user_avatar/community.icinga.com/bkai/32/841_2.png) [@bkai](https://community.icinga.com/u/bkai)\
**Post date:** [September 30, 2021, 3:06pm UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/6 "2021-09-30T15:06:11Z")

</div>

You need to show us the 2 notification rule definitions for SMS and mail. In fact all the rules addressing the same objects (target address(es) to be notified, hosts/services, time periods).

It is my experience with Icinga, at least up to & including 2.10, that the tuple containing these objects (i.e. all that is contained in the brackets in my 1st paragraph) must not be identical for different rules, otherwise you have a “last one wins” situation during “apply” time, i.e. when you activate the configuration.

Also, be very careful using “interval=0”; make sure you truly understand how this works: Once the host/service has gone into the erroneous state that triggers the notification, a notification will be sent; if the state never changes from this again in the meantime, no further notifications will be sent again! We have learnt to avoid using “interval=0” - we just set very high values.

I’m guessing here & there, of course, but perhaps we blind chickens wil find a corn! 🙂

---

<div class="post-metadata">

**Author:** ![queoadmin](https://community.icinga.com/letter_avatar_proxy/v4/letter/q/d07c76/32.png) [@queoadmin](https://community.icinga.com/u/queoadmin)\
**Post date:** [October 4, 2021, 9:31am UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/7 "2021-10-04T09:31:33Z")

</div>

Hi Kai,

here my complete configuration for E-Mail an SMS:

> object NotificationCommand “mail-service-notification” {  
> command = [ConfigDir + “/scripts/mail-service-notification.sh”]
> 
> arguments += {  
> “-4” = “$notification\_address$”  
> “-6” = “$notification\_address6$”  
> “-b” = “$notification\_author$”  
> “-c” = “$notification\_comment$”  
> “-d” = {  
> required = true  
> value = “$notification\_date$”  
> }  
> “-e” = {  
> required = true  
> value = “$notification\_servicename$”  
> }  
> “-f” = {  
> value = “$notification\_from$”  
> description = “Set from address. Requires GNU mailutils (Debian/Ubuntu) or mailx (RHEL/SUSE)”  
> }  
> “-i” = “$notification\_icingaweb2url$”  
> “-l” = {  
> required = true  
> value = “$notification\_hostname$”  
> }  
> “-n” = {  
> required = true  
> value = “$notification\_hostdisplayname$”  
> }  
> “-o” = {  
> required = true  
> value = “$notification\_serviceoutput$”  
> }  
> “-r” = {  
> required = true  
> value = “$notification\_useremail$”  
> }  
> “-s” = {  
> required = true  
> value = “$notification\_servicestate$”  
> }  
> “-t” = {  
> required = true  
> value = “$notification\_type$”  
> }  
> “-u” = {  
> required = true  
> value = “$notification\_servicedisplayname$”  
> }  
> “-v” = “$notification\_logtosyslog$”  
> }
> 
> vars += {  
> notification\_address = “$address$”  
> notification\_address6 = “$address6$”  
> notification\_author = “$notification.author$”  
> notification\_comment = “$notification.comment$”  
> notification\_type = “$notification.type$”  
> notification\_date = “$icinga.long\_date\_time$”  
> notification\_hostname = “$host.name$”  
> notification\_hostdisplayname = “$host.display\_name$”  
> notification\_servicename = “$service.name$”  
> notification\_serviceoutput = “$service.output$”  
> notification\_servicestate = “$service.state$”  
> notification\_useremail = “$user.email$”  
> notification\_servicedisplayname = “$service.display\_name$”  
> }  
> }
> 
> object NotificationCommand “sms-service-notification” {  
> command = [ConfigDir + “/scripts/sms-service-notification.sh”]
> 
> arguments += {  
> “-4” = “$notification\_address$”  
> “-6” = “$notification\_address6$”  
> “-b” = “$notification\_author$”  
> “-c” = “$notification\_comment$”  
> “-d” = {  
> required = true  
> value = “$notification\_date$”  
> }  
> “-e” = {  
> required = true  
> value = “$notification\_servicename$”  
> }  
> “-f” = {  
> value = “$notification\_from$”  
> description = “Set from address. Requires GNU mailutils (Debian/Ubuntu) or mailx (RHEL/SUSE)”  
> }  
> “-i” = “$notification\_icingaweb2url$”  
> “-l” = {  
> required = true  
> value = “$notification\_hostname$”  
> }  
> “-n” = {  
> required = true  
> value = “$notification\_hostdisplayname$”  
> }  
> “-o” = {  
> required = true  
> value = “$notification\_serviceoutput$”  
> }  
> “-r” = {  
> required = true  
> value = “$notification\_usermobile$”  
> }  
> “-s” = {  
> required = true  
> value = “$notification\_servicestate$”  
> }  
> “-t” = {  
> required = true  
> value = “$notification\_type$”  
> }  
> “-u” = {  
> required = true  
> value = “$notification\_servicedisplayname$”  
> }  
> “-v” = “$notification\_logtosyslog$”  
> }
> 
> vars += {  
> notification\_address = “$address$”  
> notification\_address6 = “$address6$”  
> notification\_author = “$notification.author$”  
> notification\_comment = “$notification.comment$”  
> notification\_type = “$notification.type$”  
> notification\_date = “$icinga.long\_date\_time$”  
> notification\_hostname = “$host.name$”  
> notification\_hostdisplayname = “$host.display\_name$”  
> notification\_servicename = “$service.name$”  
> notification\_serviceoutput = “$service.output$”  
> notification\_servicestate = “$service.state$”  
> notification\_usermobile = “$user.vars.mobile$”  
> notification\_servicedisplayname = “$service.display\_name$”  
> }  
> }
> 
> template Notification “mail-service-notification” {  
> command = “mail-service-notification”
> 
> states = [OK, Warning, Critical]  
> types = [Problem, Recovery]
> 
> vars += {  
> // notification\_icingaweb2url = “[https://www.example.com/icingaweb2](https://www.example.com/icingaweb2)”  
> notification\_from = “Monitoring [icinga@our.domain.com](mailto:icinga@our.domain.com)”  
> notification\_logtosyslog = false  
> }
> 
> period = “24x7”  
> }
> 
> template Notification “sms-service-notification” {  
> command = “sms-service-notification”
> 
> states = [OK, Warning, Critical]  
> types = [Problem]
> 
> vars += {  
> // notification\_icingaweb2url = “[https://www.example.com/icingaweb2](https://www.example.com/icingaweb2)”  
> notification\_from = “Monitoring [icinga@our.domain.com](mailto:icinga@our.domain.com)”  
> notification\_logtosyslog = false  
> }
> 
> period = “24x7”  
> }
> 
> apply Notification “mail-service-notification” to Service {  
> import “mail-service-notification”  
> interval = 0 // disable re-notification
> 
> if (service.vars.notificationgroups != “”) {  
> user\_groups = service.vars.notificationgroups  
> } else {  
> user\_groups = host.vars.notificationgroups  
> }
> 
> assign where service.name && service.vars.notificationtype != “norecovery”  
> }
> 
> apply Notification “sms-service-notification” to Service {  
> import “sms-service-notification”  
> interval = 0 // disable re-notification
> 
> if (service.vars.notificationgroups != “”) {  
> user\_groups = service.vars.notificationgroups  
> } else {  
> user\_groups = host.vars.notificationgroups  
> }
> 
> assign where service.vars.priority == “high” || (service.vars.priority == null && host.vars.priority == [“high”])  
> }

Do you see something wrong?

We set `interval=0` in order to avoid renotification of the service… Is it wrong?  
I read [Monitoring Basics - Icinga 2](https://icinga.com/docs/icinga-2/latest/doc/03-monitoring-basics/#disable-re-notifications) so I unterstood, that if we don’t want to receive many notification for the same error, we have to set it to 0…  
Do I understand wrong?

Thanks a lot  
Luca

---

<div class="post-metadata">

**Author:** ![theFeu](https://community.icinga.com/user_avatar/community.icinga.com/thefeu/32/7277_2.png) [@theFeu](https://community.icinga.com/u/theFeu)\
**Post date:** [October 5, 2021, 7:38am UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/8 "2021-10-05T07:38:50Z")

</div>

Heyhey,  
We always love to see posts formatted according to the [formatting guidelines](https://community.icinga.com/t/create-topics-and-master-markdown-formatting/69) - like if you put it in triple backticks ``` your config folds in nicely and makes everything a lot more readable 🙂

---

<div class="post-metadata">

**Author:** ![bkai](https://community.icinga.com/user_avatar/community.icinga.com/bkai/32/841_2.png) [@bkai](https://community.icinga.com/u/bkai)\
**Post date:** [October 7, 2021, 12:01pm UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/9 "2021-10-07T12:01:01Z")

</div>

I don’t see any errors in your definitions, except that those tuples I mentioned are exactly the same for both types. Try e.g. not defining separate variables for the notification user (I assume that’s the recipient), but just a generic “notification user” and THEN setting different contacts in this for mail & SMS templates. That way you might “break the tuple”…

Concerning “interval=0”, the problem with that is only that, **if you exclude recovery notifications** , which many people do (or many customers don’t want to see), and which you have done in your SMS case, the Icinga2 logic says “this host/service went CRITICAL and I did my duty and notified once, and since then I have not received any trigger that there’s been a recovery”!! I.e. you need to shut-down/re-trigger somehow after a milestone duration of a notification rule, so that the “interval” sending rule of mail/SMS is “reset”… So we now tend to avoid using “interval=0” altogether… 🙂

---

<div class="post-metadata">

**Author:** ![queoadmin](https://community.icinga.com/letter_avatar_proxy/v4/letter/q/d07c76/32.png) [@queoadmin](https://community.icinga.com/u/queoadmin)\
**Post date:** [October 8, 2021, 7:59am UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/10 "2021-10-08T07:59:26Z")

</div>

Hi Kai,

> [@bkai](#):
>
> I don’t see any errors in your definitions, except that those tuples I mentioned are exactly the same for both types. Try e.g. not defining separate variables for the notification user (I assume that’s the recipient), but just a generic “notification user” and THEN setting different contacts in this for mail & SMS templates. That way you might “break the tuple”…

I’m feeling very dumb, but I really don’t understand what you mean…  
Maybe could you make an example?

> [@bkai](#):
>
> Concerning “interval=0”, the problem with that is only that, **if you exclude recovery notifications** , which many people do (or many customers don’t want to see), and which you have done in your SMS case, the Icinga2 logic says “this host/service went CRITICAL and I did my duty and notified once, and since then I have not received any trigger that there’s been a recovery”!! I.e. you need to shut-down/re-trigger somehow after a milestone duration of a notification rule, so that the “interval” sending rule of mail/SMS is “reset”… So we now tend to avoid using “interval=0” altogether… 🙂

Do you mean, that Icinga send only **one** notification (the E-Mail) and then, due to the “interval=0” does not send the SMS?  
Then I can’t understand why we do receive SMS if the problem happens outside the downtimes…  
Or maybe I didn’t understood your explanation… 😅

Thanks  
Luca

---

<div class="post-metadata">

**Author:** ![queoadmin](https://community.icinga.com/letter_avatar_proxy/v4/letter/q/d07c76/32.png) [@queoadmin](https://community.icinga.com/u/queoadmin)\
**Post date:** [October 11, 2021, 2:42pm UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/11 "2021-10-11T14:42:01Z")

</div>

Hi again,

I discovered a very very strange behaviour…  
Currently my template for `sms-service-notification` is:

> template Notification “sms-service-notification” {  
> command = “sms-service-notification”
> 
> states = [OK, Warning, Critical]  
> types = [Problem]
> 
> vars += {  
> // notification\_icingaweb2url = “[https://www.example.com/icingaweb2](https://www.example.com/icingaweb2)”  
> notification\_from = “Monitoring [icinga@our.domain.com](mailto:icinga@our.domain.com)”  
> notification\_logtosyslog = false  
> }
> 
> period = “24x7”  
> }

and it does **not** work as expected (I don’t get an SMS is the service has a problem during the downtime).

Now I changed the used types in:

> types = [Problem, Recovery]

same as `mail-service-notification`.  
And so I get the SMS even if the service had a problem during the downtime, as expected (of course, after the downtime).

For me this seems to be a bug, since I cannot believe, that I must have more than one types…

Your opinion?

Thanks  
Luca

---

<div class="post-metadata">

**Author:** ![leeclemens](https://community.icinga.com/user_avatar/community.icinga.com/leeclemens/32/1283_2.png) [@leeclemens](https://community.icinga.com/u/leeclemens)\
**Post date:** [October 11, 2021, 4:24pm UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/12 "2021-10-11T16:24:10Z")

</div>

Are you saying it went down while in downtime, but also recovered during downtime but you received the Recovery notification after the downtime expired? Perhaps a screenshot of your History page would help put the timeline together?

---

<div class="post-metadata">

**Author:** ![queoadmin](https://community.icinga.com/letter_avatar_proxy/v4/letter/q/d07c76/32.png) [@queoadmin](https://community.icinga.com/u/queoadmin)\
**Post date:** [October 12, 2021, 6:22am UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/13 "2021-10-12T06:22:24Z")

</div>

No, I sayd, it went down during the downtime and **remain down** after the downtime.  
Then, I only receive an E-Mail and not an SMS, too.

And in my last post I sayd, that if I add another type in the `types` option of the SMS template, it works as expected, so I suppose a bug?

Thanks  
Luca

---

<div class="post-metadata">

**Author:** ![log1c](https://community.icinga.com/user_avatar/community.icinga.com/log1c/32/2071_2.png) [@log1c](https://community.icinga.com/u/log1c)\
**Post date:** [October 12, 2021, 1:10pm UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/14 "2021-10-12T13:10:59Z")

</div>

I’m not sure if it is a bug, but there is one about hosts not sending notifications after downtimes:

> <https://github.com/Icinga/icinga2/issues/7758>
>
> \## Describe the bug
> 
> I have a HA-setup (master zone with two masters, satellit…e zone with two satellites) and experience the following problem:
> 
> If a host is DOWN and a downtime get set the attribute \`no\_more\_notifications\` for the host will \_not\_ reset from \`true\` to \`false\`. But only if the downtime ends "on its own"/automatically.
> !\[image\](https://user-images.githubusercontent.com/24474580/72504881-0539f180-383f-11ea-9616-6c1ad49f0f89.png)
> 
> If you manually remove the downtime before its ended the status is reset correctly:
> !\[image\](https://user-images.githubusercontent.com/24474580/72504924-200c6600-383f-11ea-9be5-589a37652078.png)
> 
> \## To Reproduce
> 
> Provide a link to a live example, or an unambiguous set of steps to reproduce this bug. Include configuration, logs, etc. to reproduce, if relevant.
> 
> 1. host is down
> 2. create downtime
> 3. host is up
> 4. downtime ends automatically
> 5. check variable via API https://localhost:5665/v1/objects/notifications?filter=match(%22myhostname%22,%20host.name)
> 
> \## Expected behavior
> 
> The attribute no\_more\_notifications should be reset to false no matter if in a downtime or not.
> 
> 
> \## Your Environment
> 
> Include as many relevant details about the environment you experienced the problem in
> 
> \* Version used (\`icinga2 --version\`): 2.11.0-1
> \* Operating System and version: centOS 7
> \* Enabled features (\`icinga2 feature list\`): \`api checker command ido-mysql mainlog notification perfdata\`
> \* Icinga Web 2 version and modules (System - About): 2.7.2

Check if this matches in your scenario.

As a rule of thumb I always configure the notification templates with types `Problem` **and** `Recovery`. Without having the `Recovery` type configured I made the experience that non of the hosts will notify ever again, because the `no_more_notifications` option will remain on `true`.  
To not get every recovery notification I filter them at the user level (some users only get `problem` notifications, some the additional `recovery`)

---

<div class="post-metadata">

**Author:** ![queoadmin](https://community.icinga.com/letter_avatar_proxy/v4/letter/q/d07c76/32.png) [@queoadmin](https://community.icinga.com/u/queoadmin)\
**Post date:** [October 13, 2021, 8:30am UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/15 "2021-10-13T08:30:15Z")

</div>

Hi,

no, my scenario is other:

1. Host (or service) in downtime
2. Host (or service) has a problem
3. Downtime ends
4. E-Mail notification will be sent, but no SMS

But, as I sayd, as I changed types and added Custom (just to add something), I’ll get SMS, too…

Thanks  
Luca

---

<div class="post-metadata">

**Author:** ![queoadmin](https://community.icinga.com/letter_avatar_proxy/v4/letter/q/d07c76/32.png) [@queoadmin](https://community.icinga.com/u/queoadmin)\
**Post date:** [October 13, 2021, 9:34am UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/16 "2021-10-13T09:34:15Z")

</div>

> [@queoadmin](#):
>
> But, as I sayd, as I changed types and added Custom (just to add something), I’ll get SMS, too…

OK, I cheered too early… This night we had the problem again. Downtime, problem, problem remains after downtime, just E-Mail sent…

Really, I don’t know what I can think…

Any other suggestion?

Thanks  
Luca

---

<div class="post-metadata">

**Author:** ![log1c](https://community.icinga.com/user_avatar/community.icinga.com/log1c/32/2071_2.png) [@log1c](https://community.icinga.com/u/log1c)\
**Post date:** [October 13, 2021, 11:07am UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/17 "2021-10-13T11:07:51Z")

</div>

If you can force this kind of behavior (e.g. with a test check) then I would do so and turn on the debuglog before.  
Then check what the log say around the time you would normally expect the SMS to arrive

---

<div class="post-metadata">

**Author:** ![leeclemens](https://community.icinga.com/user_avatar/community.icinga.com/leeclemens/32/1283_2.png) [@leeclemens](https://community.icinga.com/u/leeclemens)\
**Post date:** [October 13, 2021, 5:34pm UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/18 "2021-10-13T17:34:15Z")

</div>

It looks like the `apply Notification` have different conditions define. Can you confirm the SMS notification is being applied to the service you are testing? `icinga2 object list --type Notification` - not sure if there’s a better way to filter that down more. You can use `--name` as well to specify the `Notification`'s name.

---

<div class="post-metadata">

**Author:** ![queoadmin](https://community.icinga.com/letter_avatar_proxy/v4/letter/q/d07c76/32.png) [@queoadmin](https://community.icinga.com/u/queoadmin)\
**Post date:** [October 14, 2021, 11:07am UTC](https://community.icinga.com/t/very-strange-icinga2-does-not-send-sms-after-downtimes/8304/19 "2021-10-14T11:07:32Z")

</div>

> [@leeclemens](#):
>
> It looks like the `apply Notification` have different conditions define. Can you confirm the SMS notification is being applied to the service you are testing?

Yes, I can confirm that, since if there is no downtime, and the host/service has a problem, we will receive an E-Mail and an SMS…  
Just if the problem happens during the downtime and remain after the downtime, we get just the E-Mail…

Thanks  
Luca