Klaxon emails you when the part of a page you care about changes

Bookmark a region, not a page

The mechanism Klaxon implements is narrower than a diff service and that is the point. Users bookmark portions of a webpage and are notified of changes to those sections, with notification by email, Slack or Discord. The bookmarking happens through bookmarklets, and the documentation for them lives in data/help.md. That distinction decides what the tool is good at. A whole-page diff tells you that something changed somewhere, which for a government disclosure log with two hundred entries is noise. A bookmark lets you point at one disclosure row, one court docket line, one entry in a release log, and get told when that specific thing moves. The README describes the intended targets plainly, including freedom of information disclosure logs and court records. The pages it watches are visited periodically, and if they have changed it emails you what is different. For a reporter who checks a log every few days by hand, this turns an open-ended chore into a notification.

Built in a newsroom, used by newsrooms

Klaxon was built and refined in the newsroom of The Marshall Project, and the README is explicit about the origin and the audience. It was created by a team of three, Ivar Vong, Andy Rossback and Tom Meagher, and supported by contributions from users around the world. The public release was supported by Knight-Mozilla OpenNews. The list of newsrooms using it includes The Marshall Project, The New York Times, The Texas Tribune, The Washington Post and the Associated Press, with a NEWSROOMS.md in the repository tracking them. What that gives the project is a credibility signal and a test set, since a tool that institutional outlets depend on gets exercised against real disclosure logs rather than toy pages. The site is newsklaxon.org and the homepage is listed as such. The relationship with MuckRock and Document Cloud is the other half of the story, because the newer hosted version is distributed as an add-on inside Document Cloud, and the original version exists alongside it.

Two versions, and only one of them is still supported

This is the most consequential fact in the repository and it is stated near the top of the README. Working with MuckRock and Document Cloud, the project launched a newer version of Klaxon that requires no server for you to maintain and very little setup, and individual users and anyone who no longer wants to run their own Heroku servers are encouraged to use that hosted tool, which is built into Document Cloud. The original version remains free and open source on GitHub, but the maintainers say they will no longer be supporting development for individual users. What they do ask for is forks, and pull requests for features that benefit the long-standing institutional users. That is a specific and workable arrangement. A newsroom that already runs Heroku can keep the self-hosted version and contribute back, and everyone else should use the Document Cloud add-on. The documentation in the repository refers solely to the original version, the one requiring you to manage your own server and email service through Heroku, which means the setup instructions below apply to that path and not to the hosted one.

Deploying the self-hosted version on Heroku

The setup goal was to make it possible for reporters and editors without a technical background to get a running instance, and the README estimates about ten minutes including the time to create Heroku and GitHub accounts if you need to. There is a Heroku deploy button that takes you to a configuration page in the dashboard. You name your app, and the name doubles as the URL, so the suggested convention is an abbreviation for your newsroom with a hyphen and the word klaxon, like wp-klaxon or sl-klaxon, which becomes a URL at https://sl-klaxon.herokuapp.com/. Then you fill in the admin_emails field with a comma-separated list of newsroom administrator addresses, and those administrators can create accounts for users in the organization as well as configure the Slack and Discord integrations. After the purple Deploy button and a card on file, Heroku builds the app, and the Manage App button takes you behind the scenes. The local build is the same application and the same commands, which is useful if your newsroom runs Docker or a Linux machine instead:

bundle install
npm install
npm run build:bookmarklet

Those three steps are the ones the Dockerfile performs before the app code is copied in, so they are the minimum needed to build the application locally.

What the free tier looked like and what it costs now

The pricing section is unusually concrete and it has changed since the project began. Heroku no longer offers a free tier, so the README says you need to be able to pay around $10 a month to get started. Out of the box that gives you 12,000 emails per month with SendGrid, 10,000 records of changes in the Postgres database, a web interface, and a scan of each watched site every ten minutes. The expansion options are priced as well. Sending up to 40,000 emails a month is a $9.95 per month upgrade to the SendGrid add-on. Storing more records costs an additional $4 a month for up to 10 million rows. Keeping the web interface running around the clock means moving the Heroku dyno from the Eco to the Hobby level for $2 more per month, which the README says is unlikely to be necessary in a smaller newsroom but is worth knowing. That ten minute scan interval is the operational heart of the service, and it is also the number to watch, since more pages watched means more requests against the sites you are monitoring.

The codebase is Rails with a Preact bookmarklet

The repository layout shows a Rails application with a JavaScript component attached to it. The top level has the usual Rails markers, a Gemfile and Gemfile.lock, a Procfile and a Procfile.dev for Heroku, a config.ru, an app/ directory, db/, lib/, spec/ and a .rspec and .rubocop.yml, plus a Dockerfile, a .devcontainer/ and install_on_ubuntu.md for people who want to avoid Heroku. The JavaScript side is separate and smaller. The package manifest is named klaxon-bookmarklet, marked private and an ES module, with build scripts that run esbuild through config/esbuild.js and a watch mode for development, and tests that run under vitest. Its dependencies are deliberately narrow: preact and @preact/signals for the UI, esbuild for bundling, typescript and vitest with a Playwright browser provider for testing. The engines field requires Node 24.x. The Dockerfile pins Ruby 3.4.8 to match the .ruby-version file, installs libjemalloc2 and postgresql-client alongside curl, builds Node 24.14.0 from source, runs bundle install with BUNDLE_DEPLOYMENT set and bootsnap precompile, then installs the node modules and builds the bookmarklet before copying the application code. That last step is the detail worth knowing, since the bookmarklet is a compiled asset that has to exist before the Rails app can serve it.

Editorial conclusion

Adopt Klaxon when you are a reporter or editor who needs to know that a specific region of a page changed, and you are either an institutional user prepared to run the server or a Document Cloud subscriber using the hosted add-on. Do not adopt the original self-hosted version as a new individual user, because the project states it is no longer supporting development for individual users, and do not expect a free tier, since Heroku no longer offers one and the documented baseline is around $10 a month. Verify first which hosting path you are on, that the pages you want to watch serve stable markup, since a redesign can break a bookmark, and that your alert volume will fit the SendGrid allowance you pick.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. themarshallproject/klaxon on GitHub