And so you have set up Nagios and whatever to always include the appropriate recipients in the messages? Where do you centralize the information about who should be @-mentioned? Edit: Seems like a lot of noise if there are a lot of recipients (some of our apps or libs have 8+ people).

HipChat has the concept of a "notify" flag for every message you send via the API.

Notified messages make a ding sound in chat, flash the task bar, etc.

For my HipChat setup, build logs are silent (and don't disturb anyone), but a notification that a deployment failed has the "notify" flag set to gain everyone's attention.

Sure, I get that. But what if a deployment failed for an app that you are not interested in (because you're not working on it) and don't want notification about it?

You have the notification goto the room for the relavent Team/Project. Then only people who are in those rooms (even when offline!) get those notifications.

As I said, I work on about 8 codebases concurrently (shared across just two or three projects). I can't have 8 chat rooms open, that's just silly. Every time I want to find a window I will have to cycle through them.

"I can't have 8 chat rooms open, that's just silly"

Why is that silly? Why would messages about all 8 projects be going into the same space? Shouldn't they be separated? That's exactly how we filter out all the different messages. And Hipchat has shortcuts to switch between different rooms, and highlights rooms that have new messages. Works pretty well, from my experience.

Do you have your email program open with 8 different mailboxes, one for each project you want to receive communications about? I doubt you do.

Notifications like these are conceptually a queue of stuff that requires your attention. There is no point in separate notifications into multiple queues, they are all equally important. If project A is throwing a fit, it doesn't matter if I'm currently working on project B, it needs my attention.

I don't know Hipchat, but with Campfire and Propane, each chat is designed to be in a separate window/tab. If you bury the room behind a kind of modal selector (as seems to be the case, there's a sidebar with each room?), that's really no better. After all, if I've focused project A and project B starts blinking, I need to switch there. That's an unnecessary switch when all I want is a queue of items to read. (And no, email is way too heavy for this, and I don't want it interleaved with my regular email. We used to use email, those were bad times.)

It's not unusual for all projects to have incidents during a day, whether it be deployment information, exceptions or monitoring alerts.

We dont do that at all, though I'm 90% sure the hipchat API supports that.

What I meant was, when a team member wants to contact me personally, they put @pbiggar in front, and Hipchat will give me a notification for that, but not all the other messages.

Yes, Campfire likes that, too. I'm talking about automated messages, though.

What I'd like is to have a list of project names I am interested in, let the bots use the project names in their messages, and then have the client ping me when something interesting is mentioned.

Propane has custom mention support where you can enter a bunch of strings, but it doesn't really work.

Use different rooms (with relavent people in each room), or make your bot smarter (we do both). You could easily make it so a given user could 'subscribe' to a project by sending a message to the bot. i.e. '@companybot subcribe xyz-service'. Then have the bot keep track of those and automatically at-message the interested people upon failures etc. IMO opinion, different rooms are still better, because it brings everyone together when there's an issue also, but it depends how large an organization you have.

We don't have a bot. Every service that does notification uses the native plugin to do so; Errbit has a Campfire plugin, Jenkins has one, etc.

While we could possibly write a custom bot that centralized everything and tied all the services together, that is going to be a fair amount of work for something that ought to exist already.