Montray brings systemd health checks to the desktop tray

Developer dimonomid has released Montray, a lightweight monitoring utility designed to bring immediate visibility to systemd service failures and custom health checks. Published on GitHub in October 2026, the tool addresses the common problem of silent background service crashes by displaying status indicators directly in the desktop system tray. It allows Linux users to monitor both local machines and remote servers without deploying complex enterprise monitoring stacks.

What happened

The project emerged from a personal frustration with silent failures in self-hosted environments. In 2021, the developer discovered that their Syncthing service had been broken for weeks, leading to significant data synchronization issues that were difficult to reconcile. Similar incidents occurred with Certbot, where certificate renewal failures went unnoticed until services expired. The core issue was that while systemd tracked these failures internally, it provided no proactive, visible alert to the user.

Montray solves this by splitting functionality into two components: a backend server and a frontend user interface. The montray-server, written in Go, runs as a background service on the target machine. It performs health checks and exposes the current status via a read-only WebSocket API. The montray-ui, built with Rust and Slint, runs on the user’s desktop. It connects to one or more server instances, aggregates their status, and displays a color-coded icon in the system tray. This architecture allows a single laptop to monitor multiple remote servers simultaneously.

The interface is designed for minimal cognitive load. A green icon indicates all systems are operational. A blinking yellow icon signals a warning, such as a non-critical service failure, while a blinking red icon indicates an error state. If the UI itself loses connection to a server, the icon blinks magenta. Users can snooze specific incidents if they wish to acknowledge them temporarily without resolving the underlying issue immediately.

Key details

• Dual-component architecture: The system separates the monitoring logic (montray-server in Go) from the display logic (montray-ui in Rust/Slint).
• Remote monitoring via SSH: The UI supports secure SSH tunnels to connect to remote servers, avoiding the need to expose monitoring ports publicly.
• Customizable checks: Beyond systemd services, users can configure arbitrary command-line checks, such as verifying disk space or RAID health.
• State indicators: The tray icon reflects the worst non-snoozed state across all monitored servers, using green, yellow, red, or magenta blinking patterns.
• Linux-focused: While the UI may run on Windows or macOS, the server’s systemd integration is specific to Linux, limiting local monitoring capabilities on other operating systems.
• Open source: The project is hosted on GitHub, with prebuilt binaries available for easy installation on Linux distributions.

Background

Systemd is the init system used by most modern Linux distributions to manage system processes and services. When a service fails, systemd records the event in its journal, but it does not inherently provide a desktop notification or visual cue to the user. For self-hosters running critical applications like file sync tools or web servers, this lack of immediate feedback can lead to prolonged downtime. Traditional monitoring solutions like Prometheus or Nagios are powerful but often require significant setup and maintenance, which is disproportionate for single-user or small-scale deployments.

Montray fills this gap by providing a "local-first" monitoring approach. It leverages the existing systemd infrastructure to detect failures but presents them in a way that is impossible to ignore for a desktop user. By using standard technologies like WebSockets for data transmission and SSH for secure remote access, it integrates smoothly into existing Linux workflows without requiring new network protocols or heavy dependencies.

Why it matters

For teams and individuals who manage their own software infrastructure, silent failures are a major risk. A backup job that stops running or a TLS certificate that fails to renew can have severe consequences if not addressed quickly. Enterprise monitoring tools are often overkill for these scenarios, requiring dedicated servers and complex configuration. Montray offers a middle ground: it is lightweight enough to run on the same machine it monitors, yet robust enough to handle multiple remote hosts.

The tool’s design respects the privacy and security constraints of self-hosting. By using SSH tunnels for remote connections, it avoids opening additional ports on firewalls or managing complex authentication tokens for external services. This makes it particularly suitable for developers who manage personal servers or small business infrastructure where security simplicity is a priority. The ability to define custom checks also means it can monitor application-specific health metrics, not just system-level service states.

What you can do

• Install locally: Download the prebuilt binaries for montray-server and montray-ui from GitHub and follow the setup instructions to monitor your local Linux machine.
• Configure systemd checks: Edit the /etc/montray-server.yml file to specify which systemd services should trigger warnings or errors, such as setting Syncthing failures as high-priority errors.
• Add remote servers: Set up montray-server on remote hosts and configure your local montray-ui to connect via SSH tunnels by editing the ~/.config/montray-ui/montray-ui.yml file.
• Define custom health checks: Add executable commands to the server configuration to monitor disk space, database connectivity, or other application-specific metrics.
• Test notifications: Trigger a test failure in a non-critical service to verify that the tray icon changes color and that desktop notifications appear as expected.
• Review documentation: Consult the project’s GitHub repository for detailed guides on security configuration, including TLS and bearer token authentication options for non-SSH setups.