Alerting
Gluesync offers two real-time notification channels — email and webhooks — so you can route system events to the tools and teams that need them. This page introduces both channels and links to the detailed configuration guides.
Notification channels
Events in Gluesync carry a severity (INFO, WARNING, or CRITICAL) and a type (for example, PIPELINE_ERROR, DATA_FLOW_STALL_DETECTED, or AGENT_RECOVERED). You decide, per channel, which events to receive and how severe they must be.
Email alerts
Email alerts are configured under Settings → Notifications → Emails. You provide an SMTP server, sender credentials, a recipient address, and then filter by event type, severity, pipeline, group, or entity. Burst prevention batches rapid-fire events into digest emails so your inbox is not flooded during large incidents.
For a full walkthrough, see SMTP configuration.
Webhook alerts
Webhook alerts are configured under Settings → Notifications → Webhooks. You can define any number of HTTP endpoints. Each webhook receives a POST request with a JSON payload following the CloudEvents specification. Per-webhook controls include event type selection, severity filtering, custom headers, signing secrets, and object scoping (pipeline, group, entity).
Gluesync also records every delivery attempt in paginated delivery logs and maintains a dead-letter queue for failed deliveries that can be retried or purged.
For a full walkthrough, see Webhook alerting.
Smart alerts
Smart alerts control when the anomaly detectors fire events. Configure global defaults under Settings → Smart alerts, then use a pipeline’s Smart alerts settings when that pipeline needs different tuning. Pipeline settings can override threshold, sensitivity, cooldown, enabled anomaly types, and the entities to monitor.
Available detectors include:
-
Latency threshold — fires when end-to-end replication latency exceeds a static limit.
-
Row count drift — fires when source and target row counts diverge beyond a percentage (developer preview).
-
Data flow stall detector — fires when an entity stops emitting batches for longer than the configured stall duration.
-
Throughput anomaly detector — uses EWMA control charts to detect statistically significant throughput drops.
-
Latency pattern detector — detects sudden spikes and sustained latency elevations against a rolling baseline.
-
Alert cooldown — minimum quiet period between repeated alerts of the same type for the same entity, preventing alert storms.
The Smart alerts page also displays a live Pattern status panel showing the health of every monitored entity, and a Simulation button that runs the current thresholds against live data without actually dispatching alerts.
When a Smart alerts threshold is exceeded, the affected pipeline or entity shows WARNING. This is a non-blocking state that needs attention; ERROR indicates an operation that has failed or cannot continue.
For details on every detector and its parameters, see Smart alerts.
Legacy logback alerting (advanced)
If you prefer file-based configuration, you can still wire Gluesync logging to an SMTP appender via Logback by setting the LOG_CONFIG_FILE environment variable to a custom logback.xml.
|
The Control Plane Notifications settings are recommended over manual XML configuration. They are faster to set up, less prone to syntax errors, do not require filesystem access, and support granular filtering and burst prevention that Logback cannot provide. |
Example logback appender
<appender name="EMAIL" class="ch.qos.logback.classic.net.SMTPAppender">
<smtpHost>smtp.gmail.com</smtpHost>
<smtpPort>587</smtpPort>
<STARTTLS>true</STARTTLS>
<username>myusername@mycompany.com</username>
<password>mysecretpassword</password>
<asynchronousSending>true</asynchronousSending>
<to>receiveremailaddress@mydomainname.com</to>
<from>mysenderemailaddress@mydomainname.com</from>
<subject>Gluesync %c{1} - %msg</subject>
<layout class="ch.qos.logback.classic.html.HTMLLayout"/>
<cyclicBufferTracker class="ch.qos.logback.core.spi.CyclicBufferTracker">
<bufferSize>1</bufferSize>
</cyclicBufferTracker>
</appender>| The larger the buffer size, the more information your alert email will contain relative to the previous error attempt. |