Incidents overview

An incident groups one or more important issues so your team can work on them together. You can declare an incident on any issue in Coalesce Quality, such as anomaly monitors, transformation layer tests (dbt, SQLMesh, Coalesce Transform) and failing Airflow tasks. An incident keeps comments and status changes in one place, shows who is working on what, and stays available for review after it is closed.

​

Open incidents

The platform gives an of open, closed, and untriaged incidents to easily track what’s being worked on and by whom.

​

Declaring an incident

Incidents can be declared through Slack alerts or directly in the UI. When you declare an incident, name it so it’s easy for everyone to understand (“duplication error from prod services impacting the ad-bidding ML model” is better than “issue with transformation model”). Declaring an incident from a Slack alert Declaring an incident from the UI

​

When to declare an incident?

What counts as an incident is up to your team. Two approaches work well:

1. For teams with few issues, all issues are declared as incidents
2. For teams with many ongoing issues, only P1 issues are declared as incidents (read more about how to assess the cost of incidents here)

​

Prioritising an incident

Not all issues are equal. Some require that you drop everything and fix it, while others can wait until the end of the week. Use the impact assessment to get an overview, including affected products, downstream products, downstream owners, and affected & downstream assets. Clicking any group will show you the specific assets that are impacted. You can also use the in-built lineage to narrow down impacted assets. For example, use the column-level lineage filter to narrow down the range of impacted assets.

​

Collaborating on issues

To indicate you’re working on an issue within an incident, change the status to Investigating. This lets everyone else see you’re on it. The activity overview shows how the status of the incident has changed over its lifetime. This is particularly helpful when an incident spans multiple issues, as not everyone may work on the same things. Use the comment section to make updates as you progress on investigating the incident.

​

Closing or canceling an incident

When the issues in an incident are resolved, the incident shows the banner below. You still have to close the incident to move it to closed incidents. You can close or cancel an incident using the Close incident button in the top right corner or Cancel incident behind the three dots. Close an incident when it is resolved and you want to keep it on record. Cancel it when the issue did not need an incident.

​

Reviewing past incidents

The lets you see all past incidents and filter by a date range. This is helpful if you want an overview of the number of incidents you declared in a time frame or if you’re looking back to investigate what happened at a specific time.

​

Managing incidents programmatically

You can declare an incident, change its state and comment on it from the API or MCP, and the team sees it in the app.

• Public API: synq.incidents.v1.IncidentsService covers incidents and synq.issues.v2.IssuesService the issues attached to them. Reading needs a token with SCOPE_INCIDENTS_READ and SCOPE_ISSUES_READ; writing needs SCOPE_INCIDENTS_EDIT and SCOPE_ISSUES_EDIT. See the API reference and API scopes.
• MCP: the issue and incident tools read open issues and incidents, their impact and their history, and the write actions declare an incident over a set of issues, edit it, set an issue’s status and post comments. Reading is covered by read-only consent; the writes need the Write permission and are attributed to you with a via MCP marker.

​

Incidents on data products

Open incidents show on the data products they affect, so everyone using a data product can see that its data may be affected.