Common Issues¶

Troubleshooting

CEL rule evaluation¶

Alert rules use CEL (Common Expression Language) expressions to decide when to fire. Mistakes in a CEL condition cause the rule to become silently inert — no alert fires and no error is shown in the UI.

Compile-time errors¶

When you save a rule, the CEL expression is compiled and type-checked immediately. If the syntax is invalid or you reference a field name that does not exist in the module's context, you will see an error at save time and the rule will not be created.

Common compile errors:

Error	Cause
`undeclared reference to 'X'`	`X` is not a valid field in this module's context
`expected type bool, found int`	The expression resolves to a non-boolean value
`syntax error`	Malformed expression — e.g. unmatched parentheses or quotes

Runtime errors¶

Some errors only appear at evaluation time — for example, type mismatches when accessing nested map fields, or calling a string method on a value that turned out to be null. When this happens:

The rule evaluation is skipped for that event.
No alert is sent.
The failure is not surfaced to the user.

If a rule that previously worked has stopped firing, consider whether the event data structure for that module may have changed.

Testing a condition¶

Use the introspection endpoint for the relevant module to see the exact shape of the event context for a real event. The Swagger UI at https://app.nob.center/docs exposes these endpoints under each module's section.

Common CEL mistakes¶

Checking for a value in a list:

# Wrong — this checks equality, not membership
changed_records == "MX"

# Correct — use exists()
changed_records.exists(r, r.type == "MX")

String comparison is case-sensitive:

# "A" and "a" are different
r.type == "A"     # matches only uppercase A records

Accessing a map field that may be absent:

# Will error at runtime if the key doesn't exist
metadata.query_status == "NXDOMAIN"

# Safer — check presence first
has(metadata.query_status) && metadata.query_status == "NXDOMAIN"

Integer vs string comparison:

# Will fail if validity_days is an int and you compare with a string
validity_days < 30      # correct (int)
validity_days < "30"    # wrong (type mismatch)

Email deliverability¶

Alert emails going to spam¶

NOB.center sends alerts from a fixed sending domain. If alert emails are landing in spam:

Add the sender address to your contacts or allowlist.
Ask your IT team to whitelist the sending domain at the mail gateway level.
Check that your template recipient address is a monitored inbox — shared aliases sometimes have aggressive spam filtering.

Alert deduplication¶

By default, the same rule will not send a second alert for the same event within a 24-hour window. This prevents repeated notifications while a condition persists.

If you receive one alert and then silence, deduplication is the most likely cause. To adjust:

Lower dedup_window_seconds in the alert template (0 disables deduplication for that template).
Note that deduplication is keyed on the rule, organization, and event data — a genuinely new event (different record, different domain) will still fire even within the window.

Batch mode delays¶

When a template is configured in batch mode, emails are not sent immediately. Instead, matching events accumulate until either:

The configured batch interval elapses (default: 1 hour), or
The batch reaches its maximum size (default: 50 events)

If you expect an immediate email after a monitored change but the template is in batch mode, the email will arrive only after the next flush.

To get immediate notifications, switch the template's frequency mode to immediate.

Template rendering errors¶

If your alert template uses a custom subject or body template and the Go template syntax is invalid, the email will fail to render and will not be sent. Double-check the template syntax if alerts are expected but not arriving.

TLS and STARTTLS connectivity¶

Certificate deployment monitoring works by connecting to a target IP address on a specified port and performing a TLS handshake to retrieve the certificate chain.

How the connection method is chosen¶

The connection method is determined automatically by the configured port:

Port	Protocol	Connection method
443, 8443, and most others	HTTPS / generic TLS	Direct TLS
25, 587	SMTP	STARTTLS
143	IMAP	STARTTLS
110	POP3	STARTTLS (STLS command)
389	LDAP	STARTTLS

For STARTTLS ports, the monitor sends the appropriate protocol-level upgrade command (e.g. STARTTLS for SMTP/IMAP, STLS for POP3) before initiating the TLS handshake. You do not need to configure this — it is determined by the port number alone.

Common connection errors¶

Connection refused or timeout

The target IP is not reachable on the configured port. Check:

Firewall rules allow inbound connections from NOB.center's scanning addresses on that port.
The service is actually listening on the configured port and IP.
The IP target is correct (not a load balancer VIP that has been decommissioned, etc.).

TLS handshake failed

The connection was established but the TLS negotiation did not complete. Common causes:

The server only supports TLS versions or cipher suites that are not mutually supported.
SNI hostname mismatch — the target_dns field on the monitor sets the SNI name used during the handshake. If the server requires a specific hostname for SNI, make sure target_dns matches.

Certificate chain cannot be verified

The server's certificate was presented, but the chain could not be validated. This happens when:

The server uses a self-signed certificate and no custom root CA is configured on the monitor.
The server is missing intermediate certificates in the chain it presents.

For self-signed certificates, add the PEM-encoded root CA to the monitor's Custom root CA field. See Certificate Deployment Monitoring for instructions.

STARTTLS negotiation failed

For SMTP/IMAP/POP3/LDAP ports, the monitor sent the STARTTLS upgrade command but the server did not respond as expected. This can mean:

The service on that port does not support STARTTLS (e.g. a non-mail service running on port 587).
The server requires client authentication before allowing STARTTLS.
The service returned an unexpected response to the protocol-level STARTTLS command.

If the service on a STARTTLS port genuinely does not speak that protocol, direct TLS will also be attempted. If both fail, the monitor will report an error.

CT-Log: no matches¶

Filter match type

The most common reason a certificate appears in CT logs but not in NOB.center is an overly narrow filter:

exact match — only the exact pattern matches. example.com will match only example.com, not sub.example.com.
wide match — matches the domain and all subdomains. example.com will match sub.example.com, mail.example.com, etc.

If you are missing certificates for subdomains, check that your filter uses wide match.

Filter is disabled or deleted

A disabled filter does not consume quota but also does not match any certificates. Verify the filter is enabled.

Certificate was issued before the filter was created

NOB.center monitors CT logs in real time. It does not retroactively scan historical CT log entries for newly created filters. Only certificates logged after the filter was created will appear.

DNS: changes not detected¶

The changed record is not in the monitored record list

DNS monitoring only detects changes for records that are explicitly listed under a domain. If a record is not in the list, changes to it are invisible.

Enable auto-discovery to have NOB.center periodically probe for common record types and add them automatically. If auto-discovery is off and you want to monitor a specific record, add it manually.

Monitoring interval

DNS domains are checked on a scheduled slot — at most once per hour. A change made shortly before the last check may not appear until the next cycle.

TTL caching

If a DNS change was made but the old value is still being returned by resolvers (due to TTL), the monitor may not detect the change until the TTL expires and the new value propagates. The monitor queries authoritative nameservers where possible to reduce this effect.

Quota limits¶

When you cannot create a new resource, you have reached the quota for that resource type on your current subscription tier.

Free up a slot without upgrading:

Disable an existing enabled resource. Disabling frees an active slot so you can create a new enabled one.
Delete a resource you no longer need.

Note: the number of disabled resources is also capped at your tier's limit. If you have too many disabled resources, delete one before disabling another.

View your current usage:

Navigate to Account Settings → Quotas to see your usage and remaining capacity for each resource type.

Increase your limits:

Upgrade to Pro from Administration → Billing. Pro limits are shown in the quota comparison table.

API authentication errors¶

401 Unauthorized¶

Your request is not authenticated. Common causes:

The Authorization header is missing entirely.
The token value is incorrect — double-check there are no trailing spaces or truncated characters.
The token has expired. Check the expiry date in Administration → API Tokens. Renew the token before it expires using the renew endpoint, or create a new one.
The token has been revoked.

403 Forbidden¶

Your token is valid but the required permission is not available. Check:

Token scopes — the token was created with specific scopes. If the scope for the operation you are attempting was not included at creation time, you need to create a new token with the correct scopes.
Role permissions — token scopes are intersected with your user's role permissions. A scope on the token only works if your role also includes that permission. If your role was changed after the token was created, the effective permission set may have narrowed.

The 403 response body will tell you which permission is missing:

{"detail": "Missing permission: create_filters in module ct-log"}