List and Retrieve Incidents
List incidents, find them by test case, status, or assignee, and read one incident with its status history through the Collate REST API and Python SDK.
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 withGET /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 exampleTASK-00001
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, andtimestamptestCaseResolutionStatusTypetestCaseResolutionStatusDetails: the assignee, or the failure reason and commentupdatedByandupdatedAttestCaseReferenceandseveritymetrics:timeToResponseandtimeToResolution, in milliseconds
Group Open Incidents
UseGET /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.groupBy,id,name,displayName, andfullyQualifiedName: 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.Severity1is the most critical. The field is absent when no incident in the group has a severity.status: the most actionable status in the group, rankedAssigned, thenAck, thenNew.statusCounts: the number of open incidents in each status, most actionable first.assignees,assigneeReferences, andassigneeCount: the distinct current assignees.firstSeenandlastSeen: when the earliest open incident in the group was opened, and the most recent status change across the group.trendandtrendDirection: the number of incidents opened in each of eight equal time buckets betweenfirstSeenandlastSeen, and a direction ofRising,Falling, orSteady.tables,tableCount,testDefinitions, andtestDefinitionCount: the related tables and test definitions, with the most open incidents first. The lists are capped, and the count fields hold the full number.
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. Useunowned=truefor the test cases that nobody owns. Don’t combineunownedwithowner. - Table:
originEntityFQN, the fully qualified name of the table.
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 anexternalReference field for storing a Jira key, but Collate doesn’t sync it for you.
To mirror incidents in a tracker such as Jira:
- Create a
Notificationalert on thetasksource with a webhook destination. See Alert for Incident Events. - In your receiver, deduplicate on the event
id. ReadentityTypeand the parsedentity. - Ignore events that aren’t incidents (
entity.categoryisn’tIncident). - Use the incident ID (
entityId) as the key that links the Jira issue and the incident, and store it on the issue. - On each event, read
entity.workflowStageIdand update the issue. - To close the loop, call Change Incident Status when the issue changes in the tracker.
- Run a periodic
GET /v1/tasks?category=Incident&statusGroup=openas a safety net, because Collate doesn’t automatically resend a webhook that failed.