← Back to home

Alert rules & timing

What Deynao watches, at what threshold it alerts, and how it avoids noise. Describes the documented version of the product.

The principle. Each rule observes a metric, compares it to a threshold, and only alerts if the condition persists (not a mere spike). The alert is then raised, explained, then resolves itself when the situation returns to normal. Thresholds are read live from the supervision engine.

The rules

Rule	Triggers when…	Severity	Scope
Authentication blocked	credentials are rejected and the auth circuit breaker arms (connection suspended without hammering Oracle)	Critical	All
Database unreachable	the database no longer responds (last collection failed)	Critical	All
Low health score	the score drops below 60 (warning) or below 40 (critical)	Variable	All
Health score not established	Deynao stops publishing a score while the database still responds: too many measurements are out of reach to compute a reliable one. While the score is missing, the "Low health score" rule can no longer warn about this database	Warning	All
Critical tablespace	a tablespace can no longer extend (autoextend maxed out and disk full), never a mere occupancy percentage	Critical	All
Backup at risk	ARCHIVELOG mode disabled, or last backup too old vs the detected cadence, or archive logs not backed up (RPO), or no backup for 90 days	Critical	Production*
Recovery area full	the FRA is ≥ 90% occupied by non-reclaimable space (risk of ORA-00257, database halt)	Critical	Production
Security below par	auditing is disabled, or the security score drops below 30	Warning	Production
Scheduled job failed	an Oracle job is broken (BROKEN, disabled by Oracle → critical) or its last run failed (warning)	Variable	Production
Collection failed	a Deynao collection module is durably down (distinct from the client's jobs)	Warning	All
Critical Oracle alerts	at least one critical alert is detected in the alert.log	Warning	All

* For "Backup at risk", the ARCHIVELOG / RPO / no-backup cases are reserved for production; an intentional NOARCHIVELOG in dev/test is not an incident.

The anti-noise safeguards

Root causes first. If authentication is blocked or the database is unreachable, Deynao raises only that alert: no point stacking symptoms on a database it couldn't probe.
Modulation by environment. Several rules (security, FRA, jobs, ARCHIVELOG mode) only apply in production. Sub-par auditing or jobs breaking during development are not incidents.
No alert on stale data. A module whose collection failed or is stale feeds no rule: no "critical tablespace" computed on a state from an hour ago.
Measures that judge the real margin. A tablespace only alerts if it can no longer extend; the FRA is judged on non-reclaimable space; the backup is compared to the cadence actually detected (daily, weekly, monthly).
Anti-false-resolution. If the data behind an active alert becomes unavailable, Deynao suspends it instead of wrongly marking it "resolved": "the data disappeared" is not "the problem is fixed".
Deliberately cautious thresholds. Deynao starts quiet, then tightens: an alerting you learn to ignore is a dead alerting.

The lifecycle of an alert

Raised once, timestamped, explained, with its recommended action.
Reminded at most once every 24 hours while it stays active. No spam.
Never lost: a failed e-mail send is retried with an increasing back-off (30 s → 1 h), never giving up, and never hammering a mail server that is down.
Resolves itself when the condition returns to normal, with its duration. The line stays viewable in the history.

Document v1.1 · updated August 2026 · distribution: public · deynao.fr/en/docs/alert-rules.html

These rules may change with product updates; the ones that apply are those in the documentation shipped with the product you installed. The thresholds shown are the default values; some may become configurable in a later version.