starred/healthchecks

Fork 0

mirror of https://github.com/healthchecks/healthchecks.git synced 2026-04-25 06:55:53 +03:00

[GH-ISSUE #171] Sending email fails silently #120

New issue

Closed

opened 2026-02-25 23:41:15 +03:00 by kerem · 6 comments

kerem commented

2026-02-25 23:41:15 +03:00

Owner

Originally created by @pslobo on GitHub (May 11, 2018).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/171

Hi,

First off, thanks for this great piece of software. Truly wonderful and perfect for my use case. I have however stumbled across a little snag while testing. Even though I have the proper settings in local_settings.py, no email is being sent (invite, verification, alert hooks etc.).

I'm stumped as to what further to try and where to look since I don't really see anything of note happening. Just silence!

Currently testing with Mailgun however I doubt that is the issue.

Would appreciate any pointer in the right direction here.

TIA

Originally created by @pslobo on GitHub (May 11, 2018). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/171 Hi, First off, thanks for this great piece of software. Truly wonderful and perfect for my use case. I have however stumbled across a little snag while testing. Even though I have the proper settings in local_settings.py, no email is being sent (invite, verification, alert hooks etc.). I'm stumped as to what further to try and where to look since I don't really see anything of note happening. Just silence! Currently testing with Mailgun however I doubt that is the issue. Would appreciate any pointer in the right direction here. TIA

kerem closed this issue

2026-02-25 23:41:15 +03:00

kerem commented

2026-02-25 23:41:15 +03:00

Author

Owner

@cuu508 commented on GitHub (May 11, 2018):

Hi,

can you post the email configuration from local_settings.py? Mask out the sensitive parts of course!

If you're using SMTP and running it locally, maybe your ISP is blocking port 25? You can try one of the alternative ports [1], say, 2525 and see if that works.

Emails are sent from a separate thread (see hc/lib/emails.py). To make sure there are no silent failures in the thread, you can put BLOCKING_EMAILS = True in local_settings.py

[1] http://blog.mailgun.com/25-465-587-what-port-should-i-use/

@cuu508 commented on GitHub (May 11, 2018): Hi, can you post the email configuration from `local_settings.py`? Mask out the sensitive parts of course! If you're using SMTP and running it locally, maybe your ISP is blocking port 25? You can try one of the alternative ports [1], say, 2525 and see if that works. Emails are sent from a separate thread (see `hc/lib/emails.py`). To make sure there are no silent failures in the thread, you can put `BLOCKING_EMAILS = True` in local_settings.py [1] http://blog.mailgun.com/25-465-587-what-port-should-i-use/

kerem commented

2026-02-25 23:41:15 +03:00

Author

Owner

@pslobo commented on GitHub (May 14, 2018):

Hi @cuu508 thanks for the prompt reply. Wasn't able to reply sooner because I was away.

This is what I have in local_settings.py:

DEFAULT_FROM_EMAIL = "monitoring@ZZZZ.com"
EMAIL_HOST = "smtp.mailgun.org"
EMAIL_PORT = 587
EMAIL_HOST_USER = "postmaster@mg.ZZZZ.com"
EMAIL_HOST_PASSWORD = "XXXXXXXX"
EMAIL_USE_TLS = True
EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend' #added later as a test, same result

ISP isn't blocking any ports here since I have monitoring (Prometheus + AlertManager) on this same server sending emails without issue using the same credentials and settings above.

I'll do a couple more tests with BLOCKING_EMAILS = True and report back.

@pslobo commented on GitHub (May 14, 2018): Hi @cuu508 thanks for the prompt reply. Wasn't able to reply sooner because I was away. This is what I have in local_settings.py: ``` DEFAULT_FROM_EMAIL = "monitoring@ZZZZ.com" EMAIL_HOST = "smtp.mailgun.org" EMAIL_PORT = 587 EMAIL_HOST_USER = "postmaster@mg.ZZZZ.com" EMAIL_HOST_PASSWORD = "XXXXXXXX" EMAIL_USE_TLS = True EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend' #added later as a test, same result ``` ISP isn't blocking any ports here since I have monitoring (Prometheus + AlertManager) on this same server sending emails without issue using the same credentials and settings above. I'll do a couple more tests with `BLOCKING_EMAILS = True` and report back.

kerem commented

2026-02-25 23:41:15 +03:00

Author

Owner

@pslobo commented on GitHub (May 14, 2018):

Ok, so did a couple of tests with BLOCKING_EMAILS = True and emails are sent. As soon as I remove that entry, I stop receiving emails. Any ideia what could be causing this? Should I keep that setting there or is that not advised.

TIA!

@pslobo commented on GitHub (May 14, 2018): Ok, so did a couple of tests with `BLOCKING_EMAILS = True` and emails are sent. As soon as I remove that entry, I stop receiving emails. Any ideia what could be causing this? Should I keep that setting there or is that not advised. TIA!

kerem commented

2026-02-25 23:41:15 +03:00

Author

Owner

@cuu508 commented on GitHub (May 14, 2018):

Ah, OK, so looks like the threads don't run. What WSGI server are you using?

With UWSGI, to make threads work you have to either run it with --enable-threads option or with --threads=N (with N > 1 I think)

@cuu508 commented on GitHub (May 14, 2018): Ah, OK, so looks like the threads don't run. What WSGI server are you using? With UWSGI, to make threads work you have to either run it with `--enable-threads` option or with `--threads=N` (with N > 1 I think)

kerem commented

2026-02-25 23:41:15 +03:00

Author

Owner

@cuu508 commented on GitHub (May 14, 2018):

A little background on this:

I implemented email sending on threads as a quick and dirty way to get them off main thread. An email is sent when user logs in -- I didn't want the login form to freeze until an email is sent over SMTP. manage.py sendalerts is also sending email notifications, and here I wanted to avoid random network hiccups and timeouts blocking any other pending tasks.

I added the BLOCKING_EMAILS setting to make testing easier. Tests set it to True in hc/api/tests/__init__.py.

It would be best to get threads to work as they are also used in manage.py sendalerts to send the other types of notifications (webhooks, slack messages, ...)

@cuu508 commented on GitHub (May 14, 2018): A little background on this: I implemented email sending on threads as a quick and dirty way to get them off main thread. An email is sent when user logs in -- I didn't want the login form to freeze until an email is sent over SMTP. `manage.py sendalerts` is also sending email notifications, and here I wanted to avoid random network hiccups and timeouts blocking any other pending tasks. I added the `BLOCKING_EMAILS` setting to make testing easier. Tests set it to True in `hc/api/tests/__init__.py`. It would be best to get threads to work as they are also used in `manage.py sendalerts` to send the other types of notifications (webhooks, slack messages, ...)

kerem commented

2026-02-25 23:41:15 +03:00

Author

Owner

@pslobo commented on GitHub (May 14, 2018):

With UWSGI, to make threads work you have to either run it with --enable-threads option or with --threads=N (with N > 1 I think)

Right on the money. After adding threads option, emails are now working correctly without BLOCKING_EMAILS = True in local_settings.py.

Also, thanks for the explanation and this wonderful and useful piece of software!

Cheers,
Pedro

@pslobo commented on GitHub (May 14, 2018): > With UWSGI, to make threads work you have to either run it with --enable-threads option or with --threads=N (with N > 1 I think) Right on the money. After adding threads option, emails are now working correctly without `BLOCKING_EMAILS = True` in `local_settings.py`. Also, thanks for the explanation and this wonderful and useful piece of software! Cheers, Pedro