Real-time monitoring of Firefox release health
Clone or download
Failed to load latest commit information.
.circleci Re-checkout code in deploy step Jul 12, 2018
frontend Don't make calculation of a summary rate depend on having a compariso… Oct 11, 2018
missioncontrol Streamline manual backfilling of data (#325) Oct 15, 2018
tests Various fixes for displaying multiple versions in the ui table view (f… Jul 18, 2018
.coveragerc Use ATMO-like build/test/deploy structure Jun 27, 2017
.dockerignore Add node_modules/docs to .dockerignore Jul 25, 2017
.env-dist Update to use error_aggregates_v2 by default May 14, 2018
.eslintrc.js Upgrade Neutrino to v7, have eslint bin use Neutrino configuration Nov 14, 2017
.gitignore Remove doc placeholders (#187) Jan 15, 2018
.neutrinorc.js Upgrade to neutrino v8 + deps and fix associated linter errors Mar 26, 2018
Dockerfile Replace tox with raw calls to pytest (#185) Jan 9, 2018
LICENSE Initial commit Jun 15, 2017
Makefile Add some notes on contributing/communicating to the README (#222) Feb 28, 2018
contribute.json Initial commit Jun 15, 2017
docker-compose.yml Bug 1473093 - Migrate to CircleCI 2.0 Jul 12, 2018
fixtures_init.sql Set default table to error_aggregates_v1 Sep 27, 2017 Initial commit Jun 15, 2017
pytest.ini Add a unit test to make sure all update_measure calls are scheduled Jan 18, 2018
sample.snappy.parquet Update dimensions list to reflect schema changes Jun 29, 2017
setup.cfg Initial commit Jun 15, 2017
yarn.lock Upgrade (react) metrics-graphics to latest (#311) Jul 17, 2018

Mission Control

CircleCI codecov

Mission Control is a monitoring service for Firefox release health, it allows you to view in (near) real time the rate of crashes and other quantitative measures of quality. It uses the dataset generated by the telemetry-streaming library.

The server-side backend is written in Python using Django. The UI is written in React, Redux and metricsgraphics.

Getting in touch

If you have any questions about Mission Control (either as a user or contributor), the best place to ask is the #missioncontrol channel on (learn more about irc @ Mozilla).


We welcome contributions to Mission Control! Working on the UI component (see instructions immediately below) does not require any special access to Mozilla's internal systems.

If you’re looking for a way to jump in and contribute, our list of good first issues is a great place to start.

Instructions for development (UI only)

If you only want to hack on the UI, you can set up a local-only of missioncontrol which pulls data from the current production server. You only need to have yarn installed.


yarn install
yarn start

This should start up a webserver at http://localhost:5000 which you can connect to.

Instructions for development (full stack)

Make sure you have docker, docker-compose, and yarn installed.

Then run:

yarn install
cp .env-dist .env
make build
make up
make fixtures

After you have brought the environment up, you can bring up a development version of the server by running make shell and then running ./ runserver from there. You should then be able to connect to http://localhost:8000 from your web browser.

By default the environment uses a rather improverished set of test data, so the environment will not be that interesting. If you have Mozilla credentials, you can set up PRESTO_URL and SECRET_KEY variables in a .env file to have it pull data from a production dataset. Once you have that set up, you should be able to download a set of recent data from a shell environment (make shell) via the load_measure_data subcommand. E.g.:

./ load_measure_data linux release main_crashes

The recommended way of running the tests locally is via the shell environment. After running make shell, execute:

pytest tests/

By default all tests and linters are run. Often you just want to run a subset of the python tests. You can do this by adding some arguments to your tox invocation:

tox -e tests -- -k tests/  # run only tests in

Instructions for deployment

The target environment for this project follows the dockerflow conventions. In order to run it correctly, a number of environment variables need to be set up. The full list of variables can be found in the web section of the docker-compose.yml file. From a services standpoint, this project requires:

  • a Postgres DB to store the application data, defined by DATABASE_URL
  • a Presto/Athena service, defined by PRESTO_URL
  • an optional Redis cache service, defined by CACHE_URL