Skip to main content
GET
GET /v1/tasks

List and Retrieve Incidents

List incidents, read one incident, and search the incident status history.
The Python examples on this page use the original client (metadata.ingestion.ometa.ometa_api.OpenMetadata) because SDK 2.0 (metadata.sdk) doesn’t include incident operations. For more information, see Which Python SDK Should I Use?.

List Incidents as Tasks

List incidents with GET /v1/tasks. Set category=Incident to return only incidents.
string
Set to Incident.
string
Set to TestCaseResolution to return only data quality incidents.
string
Task status, for example Open, InProgress, or Completed.
string
open or closed. Use this instead of status to get all open or all closed incidents.
string
Name of the assigned user or team.
string
Fully qualified name of the test case the incident is about.
string
Domain of the incident.
string
Critical, High, Medium, or Low.
integer
Return incidents created at or after this Unix epoch timestamp in milliseconds.
integer
Return incidents created at or before this Unix epoch timestamp in milliseconds.
string
Comma-separated fields to include, for example payload,assignees,about.
integer
default:"10"
Number of results per page. Use before and after for paging.
GET /v1/tasks

Retrieve One Incident

Retrieve one incident by ID or by task number.
  • By ID: GET /v1/tasks/{id}
  • By task number: GET /v1/tasks/name/{taskId}, for example TASK-00001
Both accept fields and include.

Response

The task response includes these fields:
string
UUID of the incident task. This is also the incident stateId.
string
Human-readable task number, for example TASK-00001.
string
Incident name, in the form Incident: <test case name>.
string
Task status: Open, InProgress, or Completed.
string
Current stage: new, ack, assigned, or resolved.
array
Transitions that apply now. Each item has id, label, targetStageId, targetTaskStatus, and requiresComment.
array
Users or teams the incident is assigned to.
object
Reference to the test case.
object
Present after the incident is resolved. Includes type, resolvedBy, resolvedAt, comment, and payload (which contains testCaseFailureReason).

Search Incident History

Use the test case incident status endpoints to search incidents by test case or time and to read the full status history. Each status record includes these fields:
  • id, stateId, and timestamp
  • testCaseResolutionStatusType
  • testCaseResolutionStatusDetails: the assignee, or the failure reason and comment
  • updatedBy and updatedAt
  • testCaseReference and severity
  • metrics: timeToResponse and timeToResolution, in milliseconds

Group Open Incidents

Use GET /v1/dataQuality/testCases/testCaseIncidentStatus/incidentGroups to count open incidents by test definition, table, or test case owner. The Incident Manager in the UI builds its grouped view from this endpoint. Resolved incidents are never included.
string
required
The dimension to group by: table, testDefinition, or owner.
string
Open status to filter by: New, Ack, or Assigned. Repeat the parameter or separate values with commas. A Resolved value returns a 400 error.
string
Name of the current assignee.
string
Current severity to filter by: Severity1 to Severity5. Repeat the parameter or separate values with commas. Use none to match incidents that have no severity.
string
Fully qualified name of a test case.
string
Domain of the incidents.
string
default:"createdAt"
The incident timestamp that startTs and endTs apply to: createdAt or updatedAt.
integer
Return incidents after this Unix epoch timestamp in milliseconds.
integer
Return incidents before this Unix epoch timestamp in milliseconds.
string
Return only one group. Use the table’s fully qualified name, the ID of the test definition or owner, or an empty value for the test cases that nobody owns.
string
default:"incidentCount"
What to order the groups by: incidentCount, severity, or lastSeen. When you sort by severity in descending order, the most severe groups come first and the groups with no severity come last.
string
default:"desc"
Direction of the ordering: asc or desc.
integer
default:"10"
Number of groups to return, from 1 to 1,000.
string
Cursor from the paging.before or paging.after value of a previous response.
integer
A 1-based page to return instead of a cursor. It takes precedence over offset.
Each group in the response includes these fields:
  • groupBy, id, name, displayName, and fullyQualifiedName: the table, test definition, or owner that the group represents.
  • incidentCount: the number of distinct open incidents in the group.
  • severity: the most critical severity in the group. Severity1 is the most critical. The field is absent when no incident in the group has a severity.
  • status: the most actionable status in the group, ranked Assigned, then Ack, then New.
  • statusCounts: the number of open incidents in each status, most actionable first.
  • assignees, assigneeReferences, and assigneeCount: the distinct current assignees.
  • firstSeen and lastSeen: when the earliest open incident in the group was opened, and the most recent status change across the group.
  • trend and trendDirection: the number of incidents opened in each of eight equal time buckets between firstSeen and lastSeen, and a direction of Rising, Falling, or Steady.
  • tables, tableCount, testDefinitions, and testDefinitionCount: the related tables and test definitions, with the most open incidents first. The lists are capped, and the count fields hold the full number.
To list the incidents behind a group, call GET /v1/dataQuality/testCases/testCaseIncidentStatus with the filter that matches the grouping:
  • Test definition: testDefinition, by name or fully qualified name.
  • Test case owner: owner, the name of a user or team that directly owns the test case. Use unowned=true for the test cases that nobody owns. Don’t combine unowned with owner.
  • Table: originEntityFQN, the fully qualified name of the table.
Add assignee, severity, domain, dateField, startTs, and endTs to match the filters that you used for the groups.

Keep an External Tracker in Sync

Collate doesn’t include a built-in Jira integration. Task responses have an externalReference field for storing a Jira key, but Collate doesn’t sync it for you. To mirror incidents in a tracker such as Jira:
  1. Create a Notification alert on the task source with a webhook destination. See Alert for Incident Events.
  2. In your receiver, deduplicate on the event id. Read entityType and the parsed entity.
  3. Ignore events that aren’t incidents (entity.category isn’t Incident).
  4. Use the incident ID (entityId) as the key that links the Jira issue and the incident, and store it on the issue.
  5. On each event, read entity.workflowStageId and update the issue.
  6. To close the loop, call Change Incident Status when the issue changes in the tracker.
  7. Run a periodic GET /v1/tasks?category=Incident&statusGroup=open as a safety net, because Collate doesn’t automatically resend a webhook that failed.