[opensourcedex]

chromium-dashboard is a free, open source monitoring & observability project written in Python and released under Apache-2.0. It has 747 GitHub stars, 507 forks and 504 open issues, and was last pushed 2 days ago. On this registry it ranks #242 of 270 tracked projects in Monitoring & Observability, with 5 head-to-head comparisons available. It gained 2 stars over the last 30 tracked days.

What is chromium-dashboard?

Chrome Platform Status is the official, Apache-2.0-licensed web application that tracks feature launches in Blink — the browser engine behind Chrome and many other web browsers — and it is built for the feature owners, browser engineers, and spec authors who guide a capability from proposal to shipped status.

What it is

Chrome Platform Status is the application behind chromestatus.com, maintained under the GoogleChrome organisation and written primarily in Python. It lives in the Chromium and Blink ecosystem: the README describes it as the official tool used for tracking feature launches in Blink, the engine that powers Chrome and many other web browsers. Beyond tracking, it guides feature owners through the Blink launch process documented at chromium.org/blink/launching-features, and it is positioned as a primary source of developer information that then ripples throughout the web developer ecosystem. The repository ships both the public-facing dashboard and a notifier backend that runs alongside it.

The concrete problem it solves is coordination and record-keeping across a large, distributed group of feature owners. Rather than leaving launch status scattered across mailing lists, design documents, and individual bug trackers, the project gives each feature a tracked state within one shared system and exposes that state to outside developers who need to know what is shipping and when. The README does not name a specific predecessor product that it replaces; it frames itself as the authoritative single source for this information rather than as a migration target from a named tool.

Key capabilities

  • Tracks Blink feature launches and walks feature owners through the launch process published at chromium.org/blink/launching-features.
  • Serves as the canonical developer-facing reference for platform feature information, per the README's stated mission.
  • Offers one-click devcontainer setup documented in .devcontainer/README.md, as an alternative to manual local installation.
  • Uses make setup to install JavaScript and Python dependencies together, with make clean-setup required after any change to package.json or requirements.txt.
  • Runs the main server and the notifier backend with make start, reachable at http://localhost:7777/.
  • Bundles and minifies TypeScript and JavaScript through make watch, and runs linting plus lit-analyzer with make lint.
  • Runs unit tests via make test against a local Cloud Datastore emulator, and Playwright visual and end-to-end tests via make pwtests, with screenshots updated by make pwtests-update and optionally narrowed with the --filename argument.

Who uses it and how

  • Chrome and Blink feature owners use it as the working surface for the launch process, updating feature state as a capability moves toward shipping.
  • Web developers and framework maintainers read chromestatus.com to learn what is shipping in the platform, since the README describes it as a primary source whose information ripples through the ecosystem.
  • Contributors run the stack locally by starting make start and browsing http://localhost:7777/, or take the devcontainer one-click path to avoid manual gcloud and Node setup.
  • Teams doing visual regression work run Playwright through make pwtests; when the GitHub CI playwright action reports image differences, contributors download the artifact .zip containing those differences rather than re-running blindly.
  • The project carries 744 stars and 505 forks, indicating a widely forked codebase alongside the upstream GoogleChrome repository.

Getting started

Clone https://github.com/GoogleChrome/chromium-dashboard and run make setup, or use the devcontainer one-click setup described in .devcontainer/README.md. Local development needs gcloud with the cloud-datastore-emulator and beta components, a Java JRE of version 8 or greater, a Python 3.11 virtual environment, and Node 24, after which make start serves the application on http://localhost:7777/.

How it compares

No comparable or replacement tools are named in the facts provided, so this project stands alone in this registry. No paid products are listed as things it replaces, so no licence, self-hosting, or cost-model contrast can be drawn from the available material.

When to use it — and when not to

A self-hoster must operate a fairly heavy toolchain: gcloud with the Cloud Datastore emulator and beta components, the Google App Engine SDK for Python, a Java JRE of version 8 or greater, Python 3.11, and Node 24, which is a substantial amount of local machinery for a dashboard. The repository shows 504 open issues against 744 stars, a high ratio that suggests a busy and not entirely tidy backlog, and the README concedes that installation errors may require consulting its later Notes section. Anyone wanting a lightweight monitoring tool that runs from a single container, or a team without App Engine and gcloud familiarity, should look elsewhere; the project suits organisations already invested in the Chromium launch process.

project readme (upstream, from github) — read inline

Chrome Platform Status

Mission

chromestatus.com is the official tool used for for tracking feature launches in Blink (the browser engine that powers Chrome and many other web browsers). This tool guides feature owners through our launch process and serves as a primary source for developer information that then ripples throughout the web developer ecosystem.

Get the code

For a one-click setup that leverages devcontainers, check out the devcontainer README. Otherwise, to continue setting up locally:

git clone https://github.com/GoogleChrome/chromium-dashboard

Installation

  1. Install gcloud and needed components:
    1. Before you begin, make sure that you have a java JRE (version 8 or greater) installed. JRE is required to use the DataStore Emulator and openapi-generator-cli.
    2. Google App Engine SDK for Python. Make sure to select Python 3.
    3. gcloud init
    4. gcloud components install cloud-datastore-emulator
    5. gcloud components install beta
  2. Install other developer tools commands
    1. node and npm.
    2. Python virtual environment: sudo apt install python3.11-venv
  3. We recommend using node version 24
    1. Use node -v to check the default node version
    2. nvm use 24 to switch to node 24
  4. cd chromium-dashboard
  5. Install JS an python dependencies: make setup
    1. Note: Whenever we make changes to package.json or requirements.txt, you will need to run make clean-setup.

If you encounter any error during the installation process, the section Notes (later in this README.md) may help.

Developing

To start the main server and the notifier backend, run:

make start

Then visit http://localhost:7777/.

To start front end code watching (TypeScript, JavaScript bundling and minification), run

make watch

To run lint & lit-analyzer:

make lint

To run unit tests:

make test

This will start a local datastore emulator, run unit tests, and then shut down the emulator.

To update test_html_rendering.html, modify the test_html_rendering method in the corresponding test file, uncomment the line that looks like:

 # TESTDATA.make_golden(template_text, 'test_html_rendering.html')

Then run the test again (and maybe one more time), and then you can revert your change of the test files.

To run the Playwright visual tests (aka end-to-end tests), the command to use is:

make pwtests

If there are errors, they will be displayed in the console. If you need to update any of the screenshot images, you will see differences in the packages/playwright/test-results directory, and if they look correct, then you can update all images for all tests with:

make pwtests-update

The updated images are also added to the screenshots directory. Images that did not need to be updated do not show up as having been changed. If you change the test file names, or the test method names, or the screenshot image file names, then new files will be generated, and you will need to manually delete the old files. You could simply delete all screenshots and update all, but that will take a fairly long time.

You can update images for just one test file by adding --filename=some_pwtest.js to the pwtests-update command. The some_pwtest.js name does not need to be a full path.

If there are error reported by the GitHub CI playwright action, you can look at the error log, but if the problem is a difference in some of the images, you should probably download the artifact .zip file containing all the differences.

There is some additional information for developers in developer-documentation.md.

Gemini Code Assist

This project is optimized for Gemini Code Assist. For detailed architectural context, local development tips, and specialized AI skills, please refer to:

Origin Trials

To test the functionality of this application locally that interacts with data from the Origin Trials API, an API key will need to be acquired. To do this, run the following command:

make dev-ot-key

Note: Only developers with access to the cr-status-staging GCP project will be able to successfully run this command. If you need to test this and you don't have access, open an issue.

Notes

  • If you get an error saying No module named protobuf or No module named six or No module named enum , try installing them locally with pip install six enum34 protobuf.

  • When installing the GAE SDK, make sure to get the version for python 3.

  • If you run the server locally, and then you are disconnected from your terminial window, the jobs might remain running which will prevent you from starting the server again. To work around this, use make stop-emulator; make stop. Or, use ps aux | grep gunicorn and/or ps aux | grep emulator, then use the unix kill -9 command to terminate those jobs.

  • If you need to test or debug anything to do with dependencies, you can get a clean start by running make clean-setup.

  • Occasionally, the Google Cloud CLI will requires an update, which will cause a failure when trying to run the development server with make start. An unrelated error message Failed to connect to localhost port 15606 after 0 ms: Connection refused will appear. Running the gcloud components update command will update as needed and resolve this issue.

WPT Coverage Evaluation using Gemini

See documentation here.

Blink components

Chromestatus currently gets the list of Blink components from the file hack_components.py.

Seed the blink component owners

Visit http://localhost:7777/admin/blink/populate_blink to see the list of Blink component owners.

Debugging / settings

settings.py contains a list of globals for debugging and running the site locally.

Deploying

If you have uncommitted local changes, the appengine version name will end with -tainted. It is OK to test on staging with tainted versions, but everything should be committed (and thus not tainted) before staging a version that can later be pushed to prod.

Note you need to have admin privileges on the cr-status-staging and cr-status cloud projects to be able to deploy the site.

Run the make target:

make staging

Open the Google Developer Console for the staging site and flip to the new version by selecting from the list and clicking MIGRATE TRAFFIC. Make sure to do this for both the 'default' service as well as for the 'notifier' service.

Alternatively, run make staging-rc to upload the same code to a version named rc for "Release candidate". This is the only version that you can test using Google Sign-In at https://rc-dot-cr-status-staging.appspot.com.

If manual testing on the staging server looks good, then repeat the same steps to deploy to prod:

make deploy

Open the Google Developer Console for the production site

The production site should only have versions that match versions on staging.

LICENSE

Copyright (c) 2013-2022 Google Inc. All rights reserved.

Apache2 License.

Analytics

Frequently asked questions

Is chromium-dashboard free to use?

chromium-dashboard is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does chromium-dashboard do?

Chrome Status Dashboard

What is chromium-dashboard written in?

chromium-dashboard is primarily written in Python. Its source is publicly available at https://github.com/GoogleChrome/chromium-dashboard, and it has 747 GitHub stars.