What changed in Tidewater.

You can now add a freshness check to any Kafka topic. Tidewater reads the timestamp of the newest message with a read-only client and compares it with the gap you expect.

• Set an expected gap per topic, or let Tidewater learn it after two weeks.
• Quiet periods such as nights and weekends are respected when you set a schedule.
• A topic with consumer lag but fresh messages is reported as a consumer problem, not a producer problem, so the alert reaches the right team.

Existing consumer group lag monitors keep working and now link to the topic they read.

When a model renames order_total to order_total_usd, the lineage graph now keeps one continuous path instead of ending one column and starting another.

Tidewater compares the compiled SQL of the old and new versions of a model and treats a column that keeps its source expression as the same column. Impact analysis for the old name now shows the same dashboards as before the rename, so a rename in review no longer hides what it will touch.

This applies to dbt Core and dbt Cloud projects on Snowflake, BigQuery and Redshift.

Alert rules can now use the owner of the affected table. Owners come from a meta.owner field in dbt, a tag in your orchestrator, or a setting in Tidewater, and you can mix the three.

• One rule can cover every pipeline: “send late data alerts to the owning team’s channel”.
• If a table has no owner, the alert goes to a fallback channel you choose, and the alert says that the owner is missing.
• The alert timeline shows who was notified and who acknowledged.

Teams that used one shared channel reported far fewer ignored alerts after the switch. The post on alert fatigue explains why.

After a scheduler restart, Airflow sometimes re-emitted events for runs that had already finished. Tidewater treated them as new runs, which could open a second alert for the same late table.

Run events are now matched on the run identifier and the logical date, so a repeated event updates the existing run. Alerts that were opened twice in the last 30 days have been merged, and their timelines keep both notifications.

Each alert rule has a new urgency setting. Urgent alerts always send at once. Everything else can wait for quiet hours to end and arrive as a single digest, grouped by owner and ordered by how many downstream tables are affected.

Quiet hours use the time zone of the person or channel being notified, not the time zone of the workspace. A late table that recovers before the digest is sent is left out of the digest and listed as resolved.

The lineage view used to draw every table it knew about. It now draws what you are looking at, plus one step in each direction, and loads the rest as you expand.

On a test warehouse with 24,000 tables the first view went from 11 seconds to 1.6 seconds at the median. Search inside the graph is unchanged, and now also finds columns.

A group is a named set of pipelines, for example “finance close” or “marketing attribution”. You can attach an owner, a freshness expectation and an alert rule to the group, and every pipeline in it inherits them.

A pipeline can belong to more than one group. When two groups disagree, the stricter expectation wins, and the pipeline page shows which group it came from.

A run that began at 23:50 UTC and finished at 00:10 UTC was shown as lasting 23 hours and 40 minutes. The duration was computed from the time of day instead of the full timestamps.

Durations are fixed for new and old runs. If a run’s wrong duration had triggered a slow run alert, that alert was closed and marked as caused by this bug.

PATCH /v1/pipelines accepts a list of changes and returns one result per pipeline, so a script that assigns owners to hundreds of pipelines makes a handful of calls instead of hundreds.

Changes are applied independently: a failure on one pipeline does not roll back the others, and the response says which ones failed and why. The Python and TypeScript clients have a new update_many method.

Connect a Spark history server and Tidewater lists each application as a pipeline run. You get status, duration, the slowest stages and the tables each application wrote.

• Slow run alerts compare an application with its own recent runs, not with a fixed number.
• Failed stages are shown on the run, with the executor error that Spark reported.
• Lineage includes the tables Spark reads and writes when the application uses the Spark SQL listener.