mission_control-jobs, a browser UI for Active Job queues

A frontend for the adapter you already run

The gem provides a Rails based frontend to Active Job adapters, and it currently supports Resque and Solid Queue. Two things in that sentence matter for an evaluator. The first is that the feature set depends on what the adapter itself offers, so the ceiling on this dashboard is the ceiling of your queue backend. The second is the minimum it guarantees. At a minimum it lets you inspect the job queues, inspect the jobs currently waiting in those queues, and inspect, retry or discard failed jobs. Everything beyond that is adapter dependent. That is a reasonable design, since pretending to support an operation the backend does not have would be worse, but it means the question to ask before installing is not what the dashboard shows but what your adapter can do. The gem is a Ruby project under MIT, and it lives in the rails organisation.

Adding the gem and mounting the engine

Installation is a Gemfile line and a bundle install.

gem "mission_control-jobs"

$ bundle install

Then the engine is mounted in routes.rb, wherever you want it reachable.

Rails.application.routes.draw do
  # ...
  mount MissionControl::Jobs::Engine, at: "/jobs"

Once authentication is set up, the interface gives you tabs for the existing queues, the jobs pending in them, the jobs in their different statuses, and the failed jobs, with the ability to discard and to retry. The screenshots in the README show the queues tab and the failed jobs tab of a simple application. The mounting point is ordinary Rails routing, which means the engine shares the host application's session, its cookies and its route helpers, an arrangement that is convenient and is also the source of most of the configuration questions that follow.

API-only apps need an asset pipeline added back

There is one installation wrinkle that catches people out, and it is specific to applications without a classic asset pipeline. If you use an API-only Rails app, or you use vite_ruby, vite_rails or another custom pipeline instead of Sprockets and Propshaft, the gem's JavaScript and CSS have to be served by something, and the README recommends adding Propshaft to the Gemfile.

gem "propshaft"

After bundle install, a deployment step has to precompile the assets, with the command shown as RAILS_ENV=production rails assets:precompile. The README also covers the Docker case for an API-only app or one where you skipped the assets pipeline, where the generated Dockerfile needs the precompile step re-added.

# Precompiling assets for production without requiring secret RAILS_MASTER_KEY
RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile

The pattern of a gem that ships JavaScript inside a Rails engine, and therefore needs your application to own the pipeline, is the practical difference between this and a self contained dashboard.

Authentication arrives closed

The default is the part of this gem worth copying. Mission Control comes with HTTP basic authentication enabled and closed, and the credentials live in the Rails credentials file under a mission_control key.

mission_control:
  http_basic_auth_user: dev
  http_basic_auth_password: secret

If no credentials are configured, Mission Control is simply not accessible, which is the right failure mode for an administrative screen. The generator sets them up for you, and a RAILS_ENV variable chooses the environment.

bin/rails mission_control:jobs:authentication:configure
RAILS_ENV=production bin/rails mission_control:jobs:authentication:configure

You can also set them by hand in the application configuration.

Rails.application.configure do
  MissionControl::Jobs.http_basic_auth_user = "dev"
  MissionControl::Jobs.http_basic_auth_password = "secret"
end

The generator route is the better path because it writes to the encrypted credentials rather than to a file in the repository.

Two ways to plug in your own authentication

If your application already has an admin user, the README suggests two mechanisms. The first is a different base controller. By default the engine's controllers extend the host application's ApplicationController, and you can point them at AdminController instead.

Rails.application.configure do
  MissionControl::Jobs.base_controller_class = "AdminController"
end

The same setting is available as config.mission_control.jobs.base_controller_class, and once you have your own base class you can turn the built-in basic authentication off with config.mission_control.jobs.http_basic_auth_enabled = false. The README also spells out a subtlety that will bite you otherwise. The base controller's code runs inside the engine, whose route helpers take precedence, so helpers that both your app and Mission Control define, like root_path, resolve to Mission Control's, and you reach your own with main_app.root_path, while helpers only your app defines still work. The second mechanism is route constraints, which keep authentication out of the engine's controllers entirely by restricting access at the point of mounting.

# config/routes.rb
Rails.application.routes.draw do
  constraints ->(request) { Session.find_by(id: request.cookie_jar.signed[:session_id])&.user&.admin? } do
    mount MissionControl::Jobs::Engine, at: "/jobs"
  end
end

Requests that do not satisfy the constraint never reach the engine, and as with the custom base controller you disable the basic authentication if you do not want both mechanisms in place.

The settings list, and the ones that change behaviour

Beyond authentication, the README documents a set of configuration values, and a few of them are more than cosmetics. The logger defaults to ActiveSupport::Logger.new(nil), which means no logging, and the note is that this is different from Active Job's logger or from the backend's configured logger, so an operator debugging a dashboard problem should look here first. delay_between_bulk_operation_batches sets how long to wait between batches when performing bulk operations such as discard all or retry all, and it defaults to 0. internal_query_count_limit caps the number of records counted when the adapter has to limit a count query, with true counts above the limit returned as INFINITY, and it defaults to 500,000, which is the setting that keeps the queue page fast on a large installation. scheduled_job_delay_threshold is the duration after which a scheduled job counts as delayed and defaults to 1.minute. The adapters list lets you register adapters beyond the one set for active_job.queue_adapter, backtrace_cleaner defaults to Rails::BacktraceCleaner.new and is used to filter backtraces on the failed jobs detail page, show_console_help defaults to true, and back_to_main_app_path sets the target of the Back to main app link, defaulting to the host app's root_path when it is available.

Releases, the test stack and a Redis service for the tests

The repository layout is a normal gem layout, with app/ holding the engine's views and assets, lib/ the library code, config/ the configuration, docs/ the documentation and images, test/ the test suite, and gemfiles/ for the appraisal style dependency matrix, plus a Rakefile, a .rubocop.yml and a .ruby-version. The docker-compose.yml in the root defines one service, a redis on the 4.0 alpine image with the port published on 6379 and a named volume for the data, which is what the test suite needs for the Resque path. The release history is recent and dense, with v1.2.0 on 2026-08-29 and both v1.3.0 and v1.3.1 on 2026-09-09, and the last push was on 2026-09-09. The licence is MIT, in MIT-LICENSE. The practical read for an adopter is that this is an actively moving engine that tracks Rails releases, so the version of Rails and the version of this gem have to be considered together when you plan an upgrade.

Editorial conclusion

mission_control-jobs fits a Rails team that runs Active Job with Resque or Solid Queue and needs an operational view of what is queued, what has failed and what to retry, without building that view themselves. It does not fit an application whose adapter offers none of the operations the dashboard needs, since the README is explicit that the feature set depends on the adapter, and it does not fit a team that wants a standalone admin tool outside the application, since the engine is mounted into the host app and inherits its routes and assets. Verify three things first: which adapter you run and whether that adapter supports retry and discard, that authentication is configured before the engine is reachable, since the default is closed but a route constraint without the basic auth switch leaves two mechanisms in place, and that your asset pipeline serves the gem's JavaScript and CSS if you are on an API-only app.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. rails/mission_control-jobs on GitHub
4. README
5. Releases