An anomaly is a configured condition match. Its value comes from clear criteria, useful evidence, and an agreed review process.
Start with your monitoring requirements.
Your project defines which variables matter and what should prompt review. SanSignal comparison conditions let you select decimal variables, an operator, and a numeric value. Configure consecutive readings and, where appropriate, a maximum sequence duration to express the intended rule more precisely.
Combine conditions using AND or OR, give the definition a recognizable name, and assign a severity. Test its target selection and evaluation before enabling it. Thresholds are applied as configured, without automatic conversion between units, so keep the selected variables and the engineering criterion aligned.
Make missing data part of the conversation.
A quiet channel can need attention just as a changing value can. Missing-signal conditions let you select variables and define a duration. This helps express expectations around the flow of readings alongside the project-specific comparison rules.
The evaluation model matters when you design the surrounding operational process. Missing-signal evaluation runs when a new, non-skipped data point arrives in the project. It does not run on an independent timer. If every source in a project stops delivering, the condition will not independently wake up to report that total silence.
Review the reading and the condition together.
Detected occurrences retain the triggering data point, captured definition information, and condition evidence. Filter by instrument, variable, severity, definition, action result, or date range to focus an investigation on the relevant records.
That evidence helps a reviewer answer concrete questions: which channel matched, what value was evaluated, and what rule applied? Pair it with the instrument history and the site context. A condition match identifies something to review; the engineering team determines its significance and the appropriate response.
Send context to the right recipients.
Attach email actions using organization contact groups and templates. Templates can include project and site context, severity, timestamp, and condition evidence. Configure a trigger cooldown to manage repeat notification attempts, and make the body useful to the person expected to review the event.
Follow action execution results after an occurrence, because notification work can continue asynchronously. Review contact lists as responsibilities change and keep application access separate: receiving an email does not grant the recipient permission to open the project's measurements.
Common questions.
Does the platform choose engineering thresholds?
No. Your team defines the variables, conditions, severity, and response procedure. The condition test helps verify configuration against the selected targets.
Does an email action guarantee inbox delivery?
No. Action results help you inspect notification progress and provider outcomes. Provider acceptance means the email service accepted the message; recipient settings and mail filtering can still affect delivery.