Are you mac user ? A cleaner way to handle notifications on macOS

moreamazingnick · February 8, 2026, 2:21pm

I used this promecode (MAL3WYFJAWFE) and here is some feedback only for the icinga2 functionality:

Discalimer : This app fetches hosts and services via icinga2 api, which is not recommended to expose via internet.

So a vpn connection or having access from the company network to the monitoring server would
be my recommendation.

Alternatively you could switch to icingaweb2 api → icingadb:
here are some notes I found in the icinga-mcp poc

docs/icinga-web-api.md

main

# Icinga DB Web API notes

This project targets the Icinga Web 2 Icinga DB Web module. The exact endpoints and filter grammar may vary by version and deployment path.

Default mapping (relative to icingaweb2 root):
- /icingadb/hosts
- /icingadb/services
- /icingadb/notifications
- /icingadb/downtimes
- /icingadb/comments
- /icingadb/hostgroups          # overview (list)
- /icingadb/servicegroups       # overview (list)
- /icingadb/hostgroup           # detail (requires ?name=...)
- /icingadb/servicegroup        # detail (requires ?name=...)
- /icingadb/host/history
- /icingadb/service/history


Endpoints are fixed to the Icinga DB Web defaults under /icingadb; environment overrides have been removed.

This file has been truncated. show original

or in a not so far away future the icingaweb2 → notifications api:

github.com/Icinga/icinga-notifications-web

application/controllers/ApiController.php

main

<?php

/* Icinga Notifications Web | (c) 2025 Icinga GmbH | GPLv2 */

namespace Icinga\Module\Notifications\Controllers;

use Exception;
use Icinga\Exception\Http\HttpBadRequestException;
use Icinga\Module\Notifications\Api\Middleware\DispatchMiddleware;
use Icinga\Module\Notifications\Api\Middleware\EndpointExecutionMiddleware;
use Icinga\Module\Notifications\Api\Middleware\ErrorHandlingMiddleware;
use Icinga\Module\Notifications\Api\Middleware\LegacyRequestConversionMiddleware;
use Icinga\Module\Notifications\Api\Middleware\MiddlewarePipeline;
use Icinga\Module\Notifications\Api\Middleware\RoutingMiddleware;
use Icinga\Module\Notifications\Api\Middleware\ValidationMiddleware;
use Icinga\Security\SecurityException;
use Icinga\Web\Request;
use ipl\Web\Compat\CompatController;
use Psr\Http\Message\ResponseInterface;

This file has been truncated. show original

The settings button here leads to a white page:

The reschedule button seems a little bit off:
x

I really like the idea of providing the instructions of how to setup the api user directly here:

The alert mute function sets a downtime for muting an alert:

This seams like a good idea at first but I would distinguish between 3 possibilities:

Muting an alert locally only on this mac
acknowledge an alert with a comment (this prevents further notification for others but does not improve an sla)
setting a downtime (this stops further notifications and “improves” the sla)

Every Icinga SLA reporting functionality counts a “scheduled downtime” as if the host or service is in a good state.

If I close MetricCupid, I can’t edit the icinga instance settings after repopening.
If I add a new one and delete it instantly the previous icinga instance is selected and editable.

I really like the pull idea and the notifications integrate nicely into the macos

Since this is obviously closed source I can’t check if the following idea is implemented or not:
I would want some certificate pinning method if the icinga2 api approach is used. Nearly every setup makes use of the IcingaCA, so almost every icinga-master certificate is selfsigned. On initial connection you could show some certificate details and store the certificate hash and only connect to the icinga instance if the hash matches. Maybe also add a pairing button or something if the certificate changes.

Best Regards
Nicolas