Skyrsoft CertOps raises a notification for the events an operator actually needs to hear about — certificate and CA expiry approaching, a revocation or suspension, a failed deployment or renewal, a request waiting on approval, and a licence approaching its own expiry, among others. Twelve event types exist today, and which ones reach an inbox is something you choose per alert rather than all-or-nothing.
How it works
Every alert is written as a notification first and delivered afterwards by a separate worker, so a slow or unreachable mail server never blocks the background job that detected the condition. Delivery goes out over whichever channels are enabled for that alert’s event type: email, webhook, or both. Email recipients are the addresses configured in Settings → Mail, unioned with the contact address on your licence — the licence address always receives alert email, so a fresh install with no recipients configured yet still tells someone when something needs attention.
Sending email
Configure exactly one sending method under Settings → Mail: a direct SMTP relay, the Gmail API authenticated with an OAuth refresh token, or Microsoft Graph authenticated app-only against an Exchange Online mailbox. A Send Test Email button sends through whichever method is currently saved, so confirming it works doesn’t require waiting for a real alert to fire.
Webhooks
An outbound webhook posts the same event as a JSON body to a URL you supply. When the destination has a secret configured, the request also carries an X-Skyrsoft CertOps-Signature: sha256=<lowerhex> header — an HMAC-SHA256 signature computed over the raw request body, for the receiver to recompute and compare. There is currently no settings page for webhook destinations: they’re managed directly through the /bff/settings/webhooks API rather than a page in the console.
Editable alert routing
Under Settings → Mail, a “Which alerts are emailed” section lists every alert rule with a friendly label and a toggle, so turning off one noisy alert — an offline-laptop notice being the common case — doesn’t mean editing anything by hand. Only whether an alert reaches email is exposed here; whether the underlying rule is enabled at all, and any threshold it uses, is configured with the feature that owns it. Some event types carry more than one rule: certificate expiry ships both a 30-day warning and a 7-day critical tier, and each is listed and toggled separately.
Licence-expiry alerts
A Pro licence approaching its own expiry raises a warning at 30 days out and a critical alert at 7, both emailed by default — the 30-day mark lines up with when licence validation itself switches to checking daily. Once past the expiry date, the alert leads with how much of the 30-day grace period remains, since the installation keeps running at full capability through grace and the real cliff is the end of that window, not the expiry date itself. A Free installation never raises this alert: with no expiry date to compare against, there is nothing for the check to trigger on.
Limits
Only the email toggle is editable from the alerts routing screen. Whether a rule is enabled at all, and any numeric threshold it uses, lives with the feature the rule belongs to rather than in one central place.
There is no settings page for webhook destinations, only the API. Configuring one today means calling /bff/settings/webhooks directly rather than filling in a form in the console.
Delivery is best-effort and lagged, deliberately. A notification is written the moment the condition is detected; the delivery worker picks it up on its own next cycle rather than sending inline, which is what keeps a slow mail server or an unreachable webhook endpoint from ever holding up the background job that found the problem.