starred/monolog

Fork 0

mirror of https://github.com/Seldaek/monolog.git synced 2026-04-26 08:05:53 +03:00

[GH-ISSUE #697] Create new GitHub Issues automatically #261

New issue

Closed

opened 2026-03-04 02:13:33 +03:00 by kerem · 5 comments

kerem commented

2026-03-04 02:13:33 +03:00

Owner

Originally created by @DavidGarciaCat on GitHub (Dec 4, 2015).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/697

Hello,

I've been using Monolog with Symfony, and I think this is an interesting tool, specially because can send an email with the error that we are logging.

However, I think that can be an interesting update if we can provide to Monolog with the expected config in order to allow the library to create new GitHub Issues automatically when (just an example) we receive a CRITICAL error.

I don't know if you are agree with me, but I think it can be useful on some kind of projects.

Cheers,

Originally created by @DavidGarciaCat on GitHub (Dec 4, 2015). Original GitHub issue: https://github.com/Seldaek/monolog/issues/697 Hello, I've been using Monolog with Symfony, and I think this is an interesting tool, specially because can send an email with the error that we are logging. However, I think that can be an interesting update if we can provide to Monolog with the expected config in order to allow the library to create new GitHub Issues automatically when (just an example) we receive a `CRITICAL` error. I don't know if you are agree with me, but I think it can be useful on some kind of projects. Cheers,

kerem closed this issue

2026-03-04 02:13:34 +03:00

kerem commented

2026-03-04 02:13:35 +03:00

Author

Owner

@robbieaverill commented on GitHub (Dec 18, 2015):

Thoughts on this - what if the same critical error is produced repeatedly for the same reason? Do you end up with n number of duplicate GitHub issues?

@robbieaverill commented on GitHub (Dec 18, 2015): Thoughts on this - what if the same critical error is produced repeatedly for the same reason? Do you end up with _n_ number of duplicate GitHub issues?

kerem commented

2026-03-04 02:13:35 +03:00

Author

Owner

@DavidGarciaCat commented on GitHub (Dec 18, 2015):

@robbieaverill 👍 You're right. Then my question is: if we are receiving the same error all the time, we should fix that error ASAP, right? And if we are sending emails, we are receiving the same error all the time, so the result is the same, but if we can create the GitHub issue automatically is more easy to handle when we work with some teammates.

@DavidGarciaCat commented on GitHub (Dec 18, 2015): @robbieaverill :+1: You're right. Then my question is: if we are receiving the same error all the time, we should fix that error ASAP, right? And if we are sending emails, we are receiving the same error all the time, so the result is the same, but if we can create the GitHub issue automatically is more easy to handle when we work with some teammates.

kerem commented

2026-03-04 02:13:35 +03:00

Author

Owner

@djallits commented on GitHub (Dec 18, 2015):

Agree w/ @robbieaverill here. For instance I run a legacy PHP application that runs a process every 5 minutes as a scheduled task. It essentially batches orders from a variety of front-end clients. It is not unusual for me to receive upwards of 200 emails about an issue. Yes, this is due to poor code. However, I would not want to spend my valuable time, nor anyone else's, closing 200 GH issues for the same LogLevel 500+ issue.

I believe this is why we pay for 3rd party monitoring and alerting (i.e. New Relic, PagerDuty, etc.).

@djallits commented on GitHub (Dec 18, 2015): Agree w/ @robbieaverill here. For instance I run a legacy PHP application that runs a process every 5 minutes as a scheduled task. It essentially batches orders from a variety of front-end clients. It is not unusual for me to receive upwards of 200 emails about an issue. Yes, this is due to poor code. However, I would not want to spend my valuable time, nor anyone else's, closing 200 GH issues for the same LogLevel 500+ issue. I believe this is why we pay for 3rd party monitoring and alerting (i.e. New Relic, PagerDuty, etc.).

kerem commented

2026-03-04 02:13:35 +03:00

Author

Owner

@quantumpacket commented on GitHub (Dec 18, 2015):

I concur with the above statements it would fill up very quickly with dupes. Maybe have the email messages or whatever make a link to https://github.com/vendor/repo-name/issues/new? That's at least one less step needed to open a Github issue.

@quantumpacket commented on GitHub (Dec 18, 2015): I concur with the above statements it would fill up very quickly with dupes. Maybe have the email messages or whatever make a link to `https://github.com/vendor/repo-name/issues/new`? That's at least one less step needed to open a Github issue.

kerem commented

2026-03-04 02:13:35 +03:00

Author

Owner

@DavidGarciaCat commented on GitHub (Dec 18, 2015):

👍 Closing this issue then, Cheers

@DavidGarciaCat commented on GitHub (Dec 18, 2015): :+1: Closing this issue then, Cheers

kerem referenced this issue

2026-03-04 03:04:13 +03:00

[PR #261] [CLOSED] ignore IDE files #1039