Yesterday we noticed an error sending email notification in the logs of our internal TeamCity installation. A quick investigation revealed that the server email sending settings are misconfigured. What was more interesting (and bitter) is that the settings were spoiled 2 weeks ago. Two weeks. All that time nobody was receiving email notifications from our internal TeamCity server! That might seem a disaster, but wait: why we had no complaints about it?
Of course we have other notifiers like Jabber, Windows tray, IDE and RSS, but still email should be the most popular. So why?
My guess is that advanced TeamCity users (who JetBrainers certainly are) do not want to be notified, they want to monitor. Web UI gives you a continuous, real-time feedback on what is going on. There are the whole bunch of additional data like the changes, commits, build running steps, own changes status and more. People may open TeamCity's web in the morning and leave it open for the whole day.
So most people either turned off the notifications at all or just did not notice them missing.
I remember our CruiseControl days when almost the only interface to the server was email. Web UI did not actually produce much more information and after all it was unbearably slow because of the build running on the same machine. Breaking email notifications in those days would mean no CI results - everyone would notice the problem in a couple of hours (or minutes, depending on the length of the builds). But not now. Things change.
Good notifications should not be underestimated. And we do improve notifications and will continue to do so. But who knows, with the tools advances, in a couple of years we may look down on email notifications like we do now on snail mail.
Getting down to earth, what we can do to prevent silly misconfiguration mistakes from going unnoticed? A possible solution is to display a warning to administrators in the web UI if any alike server error occur. Filed as TW-4552.