Notification rules
A rule answers one question: how many days before a certificate expires do you want to hear about it, and where should that go.
Expiry is the only thing a rule reacts to. Weak keys, broken chains and compliance failures show up in the app, but no rule fires on them.
You need the operator or owner role. Viewers cannot open Notification Rules.
How a rule is built
Section titled “How a rule is built”| Part | What it does |
|---|---|
| Conditions | Decide which certificates the rule owns. At least one is required, and NoCert refuses to save a rule without one. The Default Rule is the exception and carries none. |
| Notify | The threshold, in days before expiry, and the targets the alert goes to. |
| Escalation | An optional second, tighter threshold, with its own targets. |
| Order | Rules are evaluated top down, first match wins. |
Conditions
Section titled “Conditions”A condition matches on one of four fields, and every condition on a rule must match. There is no OR: for that, write two rules.
| Field | Matches against | Operators |
|---|---|---|
CN |
The certificate’s common name. | contains, equals |
SAN |
Any one of the certificate’s subject alternative names. | contains, equals |
Tag |
Tags you put on the endpoints where the certificate was seen, not on the certificate. | equals |
Is CA |
Whether the certificate is a CA. | equals true |
Matching ignores case. There are no wildcards and no regular expressions, so a * in a value is a literal asterisk. That is exactly how the seeded Wildcard certificates example works: CN contains *.
A tag condition is stricter than it looks. When a rule carries several tag conditions, one endpoint has to carry all of them. Spreading the tags over two endpoints does not match.
A tag also needs an endpoint to live on. A certificate NoCert only ever saw in a file or a Kubernetes object has none, so a tag condition can never match it, and the rule passes it to whatever comes next.
Order and the default rule
Section titled “Order and the default rule”NoCert walks your rules from top to bottom and stops at the first one that matches. Drag a rule to change where it sits.
Turn on continue evaluation on a rule if you want matching to carry on past it, so a certificate can notify two teams. It carries on through your own rules only: once any rule of yours has matched, the Default Rule is skipped whatever you set here.
The Default Rule sits at the bottom and takes everything the rules above did not claim. You can change its name, its threshold, its targets and its escalation. You cannot delete it, disable it, or give it conditions.
Disabling a rule hands its certificates to whatever matches next, usually the default rule. It does not silence them.
Pro allows ten rules of your own and Business twenty, disabled ones included. The Default Rule does not count against either, since you did not create it.
Escalation
Section titled “Escalation”Escalation is a second threshold, not a delay. A rule set to notify at 30 days and escalate at 7 sends to its own targets from day 30, and adds the escalation targets from day 7.
Both are days before expiry. There is no way to say “if nobody acknowledges within 4 hours”.
When alerts actually arrive
Section titled “When alerts actually arrive”NoCert sends one digest a day, at or after 08:00 UTC. That hour is fixed for every customer, so a certificate discovered at 09:00 waits until tomorrow.
Inside that daily run, how often a given certificate reappears depends on how close it is:
- More than 7 days out: once every 7 days.
- 7 days or fewer, including already expired: once a day.
Delivery is not retried. If a channel fails, the next attempt is the next cadence window, so a certificate 20 days out will not be tried again for a week.
Why a certificate you expect never alerts
Section titled “Why a certificate you expect never alerts”Five conditions silence a certificate before your rules are consulted:
- Muted. Muting is per certificate and lasts until you undo it. Use the actions menu on the certificate row, the bell icon in its detail header, or the link in the alert email. Operators and owners only.
- Excluded. Excluding a certificate from the inventory takes it out of alerting too. Restore it from the Excluded tab on Certificates.
- Not seen for six days. A certificate NoCert has not observed on the network for six days is treated as decommissioned and stops alerting, however expired it is. The rule editor says as much under the threshold field.
- Very short-lived. A certificate whose whole validity is 7 days or less is assumed to be on automatic rotation, so approaching-expiry alerts are suppressed. One that actually expires while still being served does alert, because that is a broken rotation.
- Long expired. Past 14 days after expiry a certificate drops out for good.
If a certificate is silent and none of those apply, check that its rule is enabled, and that your trial or subscription is still active. Expiry alerting stops for the whole organization when a trial runs out.
One run also loads a bounded number of certificates per organization, deferring the ones furthest from expiry when an estate is very large. It is not a promise that nothing is ever missed, which is why the rules you write matter more than the Default Rule catching everything.
Separate from your rules
Section titled “Separate from your rules”Certificates found on a host’s disk that no longer match what the host is serving generate their own notification. That one ignores rules, conditions and ordering: it goes to every enabled channel on every target in the organization. Muting the certificate does not stop it.
It needs the local scan to have run on that host, since the comparison is against what the host was observed serving. A host with filesystem findings and no local scan never produces one. The digest lists 50 findings and counts the rest.