Alerts: One Timeline Across Every Source
Monitors, flows, credentials and domains all write to one alert table with a shared lifecycle, and the same problem never alerts twice.
Every source in SensaCat writes to one alerts table. A silent monitor, a stalled flow instance, an expiring credential and a domain that stopped responding all appear in the same timeline with the same lifecycle.
The reason is practical rather than architectural. During an incident you want one place to look, and four separate feeds means correlating timestamps by hand at exactly the moment you have least patience for it.
Six source types, three of them for domains
| source_type | Raised when |
|---|---|
| monitor | A monitor passes its interval plus grace, or reports an explicit failure |
| sequence_instance | A flow instance is overdue for its next step |
| credential | A credential enters a reminder zone |
| domain_uptime | Two or more consecutive failed checks |
| domain_ssl | Certificate expiry enters a reminder zone |
| domain_registration | Registration expiry enters a reminder zone |
Domains get three source types rather than one on purpose. A domain can be down and have a certificate expiring in four days at the same time, and those are different problems with different fixes and different owners.
Collapsing them into a single domain alert would mean the second problem hides behind the first, and resolving the outage would appear to resolve the certificate warning too.
Lifecycle
An alert opens, gets acknowledged or escalates, and resolves. Resolution can be manual or automatic.
| Status | Meaning | How it gets there |
|---|---|---|
| open | Raised, nobody has responded | Detection sweep |
| acknowledged | Someone has taken it | Manual, stops escalation |
| escalated | Unacknowledged past the escalation window | Automatic, re-notifies the group |
| resolved | The underlying problem cleared | Automatic on recovery, or manual |
Automatic resolution is the part that keeps the list usable. A monitor that starts pinging again resolves its own alert; a credential whose expiry date is updated resolves its own alert. You are not left acknowledging a backlog of problems that fixed themselves overnight.
The same problem does not alert twice
A detection sweep runs every few minutes. Without idempotency, a monitor that has been silent for a day would raise a fresh alert on every sweep: at a 5-minute cadence that is 288 alerts describing one problem, arriving overnight.
An index on source type and source ID is checked before any alert is created, so an open alert for a given source suppresses duplicates. One problem produces one alert, which stays open until it clears.
This is also why acknowledging works the way it does. Acknowledgement stops escalation without closing the alert, because the problem is still real until the underlying condition changes.
Retention by plan
| Free | Starter | Team | Enterprise | |
|---|---|---|---|---|
| Alert history | 7 days | 30 days | 90 days | Unlimited |
| Acknowledge and resolve | Yes | Yes | Yes | Yes |
| Escalation | No | Fixed 30 min | Configurable | Configurable |
If you need history beyond your tier's retention for audit or review purposes, export it on a schedule into your own storage. The API returns alerts filtered by date, which makes a nightly export a short shell script.
Completions are not alerts
A business flow that finishes successfully with completion notices enabled produces an informational notice, not an alert row. Nothing needs acknowledging and nothing needs resolving, so putting it in the alert timeline would be noise.
Completions appear in their own dashboard panel, styled as successes rather than sitting in a problem log. Keeping those two things visually distinct is a small decision that makes the dashboard readable at a glance.
Current limitation
Alert history records what happened. There is no tamper-evident audit trail of configuration changes today, so you cannot yet demonstrate that an alert threshold was never widened or that a monitor was never disabled.
If that is a compliance requirement, read integration monitoring for regulated industries, which explains what to require and where we currently fall short.