Skip to main content

Community

Slack notifications for connection failures, delays and schema changes

Answered

Please sign in to leave a comment.

Comments

2 comments

  • Official comment

    Hi there,

    Thanks for submitting this request! We've added "Slack notifications for connection failures, delays and schema changes" to our feature improvements backlog and it's under active consideration.

    I'd love to learn more about your specific use case — what problem are you trying to solve? Any additional context will help us prioritise effectively. For example, what are the specific connector types, data sources/ destinations you are tracking notifications?

    Thanks,
    Dipti

    Hi Dipti,

    Thanks for the quick response, and here's more context on how we'd use it.

    The problem we're solving: 
    Our data and engineering team manages pipeline issues in Slack. When a connection breaks, the delay between the failure and someone noticing is what hurts, because downstream dashboards and models quietly go stale. Email alerts get missed or buried, and building a relay just to get alerts into Slack adds another thing that can fail silently.

    Two additions beyond my original request

    1. Webhook event alerts. For webhook-based connections, we'd like notifications for when data is received, when events fail to process, and when no events have arrived within an expected window. A webhook source that goes quiet often looks healthy from the sync status alone.

    2. Data freshness / staleness alerts. Something like what Metaplane offers: set an expected freshness per connection or table (e.g. "this table should update at least every 6 hours") and alert when it's exceeded, even if the sync technically reports success. Volume anomalies (e.g. a sync that lands far fewer rows than usual) would be a great bonus. Today we'd need a separate observability tool for this, and it would be much simpler to have it where the pipelines already live.

    Why it matters most for SDK connectors
    Our Connector SDK connections are the ones most likely to break when a source API changes, and the failure mode is often partial: the sync runs but returns empty or incomplete data. Freshness and volume checks would catch those cases that a plain failure alert wouldn't.

    Thanks! Sam