Noticed: Multi-Channel Notifications for Ruby on Rails

What problem Noticed solves, and for whom

A Rails app that grows past its first mailer usually ends up with notification logic scattered across callbacks, jobs and controllers. One event, like a comment being posted, has to reach a browser over ActionCable, an inbox over email, and a team chat over Slack, and each of those paths has its own retry behaviour, its own recipient list and its own content. Noticed's answer is to make the event itself the unit of code. A Notifier class declares which delivery methods apply, and the gem handles the fan-out.

The README frames this as two shapes of delivery. Individual deliveries give each recipient their own notification with their own content; the car dealership example in the README has the buyer, the salesperson and the bank each receiving a different message about the same sale. Bulk deliveries are a single notification for many recipients, which the README says are typically used to push to platforms where users are managed elsewhere, such as Slack or Discord. If your team argues about whether a notification belongs in the app or in chat, that distinction is the design axis Noticed is built around.

Notifiers, delivery methods and Notification records

Noticed operates with three constructs the README names directly: Notifiers, delivery methods, and Notification records. A Notifier inherits from Noticed::Event. Inside it you call deliver_by for per-recipient channels and bulk_deliver_by for shared ones, each with a configuration block that yields a config object. The README states that procs and lambdas in that block are evaluated when needed, that a lambda receives no arguments and is evaluated in the context of the Noticed::Notification, and that a symbol instead calls a method with the notification object passed as an argument. That is the mechanism that lets a single Notifier read per-recipient state, such as whether someone opted into email.

Content lives in a notification_methods block. The README's example defines message using an I18n helper and url using Rails URL helpers, and it notes that default_url_options must be set for URL generation to work. Delivery methods the README lists as officially supported include ActionCable, Action Push Native, Apple Push Notification Service, Email, Firebase Cloud Messaging, Microsoft Teams, Slack, Twilio Messaging for SMS and WhatsApp, Vonage SMS, and a Test method. Bulk methods listed are Bluesky, Discord, Slack and Webhook. Each has its own file under docs, which is where the per-method configuration detail actually lives.

Installing Noticed and sending a first notification

Installation is two steps in the Gemfile and two in the database. The README gives this command to add the gem:

bundle add "noticed"

Then the migrations are copied into the host app and run, which is the point where Noticed stops being a library and starts owning tables in your schema:

rails noticed:install:migrations
rails db:migrate

The generator creates the Notifier class. The README uses NewCommentNotifier as its example:

rails generate noticed:notifier NewCommentNotifier

The generated class is where you declare channels. This is the README's example, with an ActionCable delivery, an email delivery gated on a recipient preference, and a bulk Discord delivery:

class NewCommentNotifier < Noticed::Event
  deliver_by :action_cable do |config|
    config.channel = "NotificationsChannel"
    config.stream = :some_stream
  end

  deliver_by :email do |config|
    config.mailer = "CommentMailer"
    config.if = -> { !!recipient.preferences[:email] }
  end

  bulk_deliver_by :discord do |config|
    config.url = "https://discord.com/xyz/xyz/123"
    config.json = -> {
      {
        message: message,
        channel: :general
      }
    }
  end
end

What you should see after wiring this up is a Notification record per recipient for the individual channels, and the ActionCable stream receiving a payload on the channel name you configured. The README points to docs/delivery_methods/action_cable.md, docs/delivery_methods/email.md and docs/bulk_delivery_methods/discord.md for the specifics of each, and those files are the ones to read before you copy the block above, because the config keys differ per method.

Where Noticed is the wrong tool

Noticed is not a mailer replacement and it is not a queue. If your application sends one transactional email on signup and nothing else, adding a Notifier class plus a migration plus a notification record per send is more machinery than the problem needs, and ActionMailer alone will be easier to debug. The gem's value appears when the same event genuinely has more than one destination.

The second constraint is the database. Noticed ships migrations into your app, so the notification records are yours to retain, query and eventually clean up. The README does not document a retention policy, a pruning task, or a rollback path for the installed migrations, so plan for the table growing and decide your own deletion strategy. The README also does not describe what happens when a delivery method fails mid-fan-out, beyond the config.if gate shown in the email example. If guaranteed delivery per channel matters to you, that is behaviour you will need to verify in the source rather than assume from the README.

Finally, the naming is a real practical annoyance. Searching for this gem returns results about the English word, songs and dictionary entries. The RELATED SEARCHES list for this project is dominated by meanings and lyrics rather than Rails. Add the repository URL to your team notes when you introduce it, or the next engineer will not find it.

How Noticed differs from a plain ActionMailer setup

The honest alternative for many Rails apps is ActionMailer plus a background job, with no extra gem. ActionMailer is built into Rails, has no migrations of its own, and every Rails developer already knows how to trace a mail through it. The difference in approach is that ActionMailer models a message, while Noticed models an event. With ActionMailer you write one mailer per destination and call it from wherever the event happens, so the knowledge that a comment triggers both an email and a browser update lives in the calling code. With Noticed that knowledge lives in a single Notifier class, and the calling code just triggers the event.

That trade is worth taking when the number of destinations per event is greater than one, and when recipients have preferences that gate channels. It is not worth taking when the answer is always the same single email. A second alternative is to push everything into your chat platform and skip in-app notifications entirely, which the README's bulk delivery section explicitly anticipates: bulk deliveries are described as typically used to push to platforms where users are managed, instead of your own. If that describes your product, you may only need bulk_deliver_by and none of the per-recipient machinery.

Maintenance status, licence and upgrade cost

The repository is not archived, and the last push was on 2026-04-08. The most recent release listed is v3.0.0 from 2025-12-31, preceded by v2.9.3 and v2.9.2 in October 2025. The presence of a major version bump, an UPGRADE.md file at the repository root, and an Appraisals setup for testing against multiple dependency versions together suggest the project is maintained and that the maintainers expect upgrades to need instructions. That is a signal about process, not a promise about your upgrade.

The licence is MIT, declared in MIT-LICENSE and in the gemspec. In practical terms that is a permissive licence with minimal obligations, but it is still your responsibility to confirm it fits your organisation's policy; this is not legal advice.

The real upgrade cost is the installed migrations and the Notifier classes in your app. Version 3.0.0 is a major release, and the README does not cover migration between versions. UPGRADE.md and CHANGELOG.md are the files that do, and reading them before you bump the gem is cheaper than reading them after. Because delivery method configuration is per-method and lives in docs, a major version can change config keys without changing the shape of your Notifier classes, which makes a diff of the docs directory the fastest way to spot what moved.

Editorial conclusion

Adopt Noticed if your Rails app already has an event worth telling people about and you want one Notifier class to fan it out to email, ActionCable, Slack and the rest. Do not adopt it if you only need a one-off mailer, or if you are not prepared to own a notifications table and its migrations. Before you commit, read UPGRADE.md and the CHANGELOG for the v3.0.0 breaking changes, and confirm the delivery methods you need (Twilio, Vonage, FCM, APNs) are documented under docs/delivery_methods in the version you pin.

Frequently asked questions

Official sources

1. excid3/noticed on GitHub
2. Issues
3. License: MIT
4. README
5. Releases