Astra Monitor puts CPU, GPU and disk meters in the GNOME top bar

The one design decision that shapes everything

Astra Monitor is described as a customizable, performance-focused monitoring extension for GNOME's top bar, and the performance claim is stated in a way that is more specific than the usual.

Resources are only queried when needed. No polling. No wasted resources. Hidden components are not queried nor rendered.

That is the architectural choice that makes this extension different from the typical top bar resource meter. Most of them run a timer that asks for a CPU percentage every second whether or not anyone is looking, and that cost is paid by every user of the extension whether or not they care about the numbers.

A query-on-demand model means the cost is proportional to how much you actually look. If you hide a component, it costs nothing at all. If you never open the menu, the detailed numbers are never fetched.

The other two claims in the key features list are about the interface rather than the plumbing. The customizable interface means you choose which resources to monitor and how to display them, with a lot of customization options available. And the effort-free real-time updates mean changes made in the preferences panel are applied instantly, with no need to restart the extension or GNOME Shell, which keeps the change from interrupting what you are doing and allows for on-the-fly customization.

The instant-apply behaviour is worth calling out for a shell extension specifically. Restarting GNOME Shell means logging out on Wayland, and restarting the extension means reloading it in the Extensions Manager. A preferences panel that takes effect without either is a real quality difference for something you will adjust several times while setting it up.

The comprehensive monitoring claim covers CPU, GPU, RAM, disk usage, network statistics and sensor readings, with more detail available inside the menus by hovering over the resource you want to know more about.

The project is TypeScript, GPL-3.0 licensed, with the last push on 2026-10-12 and releases v43 from 2026-10-11, v42 from 2026-08-11 and v41 from 2026-06-28.

Installing it, and the NixOS case

Astra Monitor can be installed on any Linux distribution supporting GNOME version 45.0 or higher, and that version floor is the first thing to check.

The most common route is the GNOME Extensions Manager, and most distributions with GNOME already have the application installed. If not, it comes from the package manager or software centre.

The other route is the GNOME Shell Extensions website, in three steps. Visit the Shell Extensions page, search for Astra Monitor, and click on the extension and follow the on-screen instructions.

For NixOS there is a configuration snippet to add to configuration.nix:

{ config, pkgs, ... }:

{
  environment.systemPackages = with pkgs; [
    gnomeExtensions.astra-monitor
  ];
}

That is the shape of a NixOS package for a GNOME extension, and the reference to gnomeExtensions.astra-monitor is the packaged extension attribute rather than a build from source.

The alternative route for NixOS users is the shell.nix file at the repository root, which is the development environment definition. The presence of shell.nix alongside a package.json and a tsconfig.json tells you the extension is developed in TypeScript against the GNOME Shell type definitions rather than being written in GJS directly.

The type definitions in the dev dependencies confirm the approach. There is @girs/gnome-shell at 47.0.0-next.4, which is the generated TypeScript types for the GNOME Shell API, and @girs/gjs at 4.0.0-beta.16 for the GJS runtime itself, plus @girs/gtop-2.0 at 2.0.0-4.0.0-beta.19, which is the Libgtop introspection data.

That last one is the reason the extension can be written in TypeScript rather than plain JavaScript, and it is also why Libgtop matters below.

One caveat about the documentation itself. The screenshots are noted as being from an outdated version of the extension and may not reflect the current release, so the visual reference is a rough guide rather than an accurate picture of what you will see.

Libgtop is optional, and the documentation is careful about that

Astra Monitor works out of the box with no additional dependencies, and the documentation is careful to say that some optional dependencies can enhance the data displayed. Those tools and the impact of their absence are clearly listed in the preferences panel of the extension.

That last sentence is the right way to handle an optional dependency. Instead of a table in the documentation that goes stale, the extension itself tells you what you are missing and what you would gain by installing it.

The first optional dependency is Libgtop. If you want to use Libgtop as a data source you may need to install the libgtop package. The package is not required for the extension to work, but it is recommended for a better experience.

The per-distribution commands are given and they are not the same command, which is the usual detail that trips people up:

sudo apt install gir1.2-gtop-2.0

sudo dnf install libgtop2-devel

sudo pacman -Syu libgtop

sudo zypper install libgtop-devel

Note the naming: on Debian and Ubuntu the package is the GObject introspection wrapper, gir1.2-gtop-2.0, because that is what a GJS extension actually loads, while on Fedora, Arch and openSUSE the development package is what provides the typelib.

For NixOS the configuration is different again, because the typelib path has to be set explicitly:

environment.variables = {
    GI_TYPELIB_PATH = "/run/current-system/sw/lib/girepository-1.0";
};
environment.systemPackages = with pkgs; [
    libgtop
];

The GI_TYPELIB_PATH variable points at the introspection repository, and without it the extension cannot find the typelib even though libgtop is installed. That is a Nix-specific wrinkle rather than a flaw in the extension, and it is the kind of thing the documentation should show and does.

The second optional dependency is Nethogs, and the section is cut off in the documentation available here. Given the pattern, the likely reason is per-process network accounting, since Nethogs is the standard tool for attributing network traffic to individual processes.

The naming convention across the GIR packages is worth noting for anyone reading the dependency list: the @girs scope covers generated TypeScript definitions for GObject introspection libraries, which is what lets an extension written in TypeScript call into Libgtop with types.

The roadmap and the comparison document

The project publishes a roadmap table, and it is worth reading because a beta project with an ambitious plan tells you what you are adopting.

The table is split into two columns of states, Beta at 3 of 6 and Release at 0 of 5. The Beta column has an approximate timeline of around 2026 and lists Help and Doc as in progress, along with Battery Monitoring and Continuous Monitoring Mode. The Release column has no date, and lists Themes, User Custom Commands and one empty slot.

The ticked and unticked boxes are the interesting part. Help and Doc is marked with a clock as in progress, Themes and User Custom Commands are unchecked, and Battery Monitoring and Continuous Monitoring Mode are also unchecked.

Continuous Monitoring Mode is the item that connects back to the no-polling design. The current behaviour is query-on-demand, and a continuous mode would be a deliberate exception to that, so it is listed as future work rather than shipped.

The full roadmap, including past releases, is in the ROADMAP.md file, and there is also a RELEASES.md at the repository root.

The other document worth knowing about is COMPARISON.md, which the overview describes as a detailed comparative analysis of Astra Monitor features, performance and benchmarks against similar projects in the same domain. A project that publishes its own benchmarks against its competitors is making a specific claim, and having the numbers in a file you can read is more useful than a claim in a bullet list.

The repository layout is consistent with a project of this kind. There are extension.ts and prefs.ts as the two entry points, src/ for the implementation, types/ for the TypeScript definitions, schemas/ with a schemas.sh script, po/ with an i18n.sh script for translations, icons/, stylesheet.css, and the screenshots/ directory. There are also compile.sh, pack.sh and test.sh as build scripts, a benchmarks/ directory, and an ego.sh script whose name suggests a way to run the extension outside a full GNOME session for development.

Where this sits against the built-in GNOME system monitor

The comparison that matters is with the tools GNOME already ships, and there are two of them that do different jobs.

GNOME System Monitor is the full graphical application. It shows a process list, a resource graph and per-process detail, and it covers more ground than a top bar extension can. What it does not do is sit in the top bar, so the answer to a glanceable question requires opening a window and waiting for it to draw.

The other comparison is with simpler third-party top bar indicators that already exist in this space, and they compete for the same screen space. They show the same rough categories of data. Astra Monitor's argument is the configuration: which resources appear, how they are formatted, and what the menu shows when you hover.

That is a real difference but a narrow one, and the honest framing is that Astra Monitor is about the top bar presentation rather than about the monitoring itself.

Where it clearly goes further is in the menu detail. The stock indicators show a number; the Astra Monitor menus show more information about the resource you are pointing at, and that is the part that is hard to reproduce with a stock indicator.

The performance claim then becomes the deciding factor, and it is the one to test for yourself. If the no-polling design works as described, then an extension that queries on demand is a better citizen on a laptop than one that polls every second, and on a desktop where the top bar is always visible that difference is a real battery story rather than a rounding error.

The comparison with the other projects in its domain is exactly what COMPARISON.md is for, and it is worth reading before choosing, because in this category the differences are in the details of what is queried and how often.

One thing to keep in mind when reading the project's own description is that it is still in the early stages of development and is constantly evolving, and the version numbering with Beta labels on the release tags reflects that.

Editorial conclusion

Adopt Astra Monitor if you run GNOME 45 or newer and want resource meters in the top bar without the overhead of a polling extension. Skip it if you are on GNOME below 45, since that is the stated floor, or if you want a graphical system monitor rather than bar indicators. Verify first which optional data sources you want, since libgtop and nethogs change what the extension can report and are listed in the preferences panel with the impact of their absence, and that you are on the current release, since the project is in beta and the screenshots in the documentation are noted as being from an outdated version.

Frequently asked questions

Official sources

1. AstraExt/astra-monitor on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases