Skip to main content

Returns a page of alarms

GET 
/alarming

Returns one page of the alarm results, filtered and sorted by the server. The alarm table grows without bound - every sweep of the condition monitoring appends to it - so there is deliberately no way to ask for all of it: the size of the answer depends on the requested page size and not on the size of the table. Because of that, the counts a client shows cannot be derived from the returned items any more and travel with the page instead: totalItems is how many alarms match the filter, totalUnfilteredItems how many exist at all, and severityCounts, statusCounts and completionStateCounts how the matching ones are spread across the severities, the statuses and the two completion states. All of them are computed from the filtered query, not from the page. A request that names no sort is answered sorted by triggeredAt descending - the alarm raised last comes first - so the same request always returns the same page in the same order. The two sort parameters fall back to that default independently. sortFields takes one of triggeredAt, updatedAt, clearedAt, title, label, severity, status, completionState, signalName and assetName; any other name is answered with 400. severity, status and completionState are sorted by rank - in the order their enums declare the values, LOW before CRITICAL, NEW before IGNORED, RUNNING before COMPLETED - not by their names. An alarm without the sorted value (never updated, still standing, without a signal or an asset) comes last in either direction. Alarms that share the sorted value follow newest first, and the alarm id is appended to whatever sort applies, because a page out of a result whose order is not unique may show one alarm twice and another never. Archived alarms (see archiveAlarm) are left out unless archiveFilter asks for them. The filter governs the page and every count that describes the result - totalItems, severityCounts, statusCounts and completionStateCounts alike. Two counts deliberately ignore it: totalUnfilteredItems counts the archived alarms too, and archiveCounts says how many alarms each archiveFilter value would show under the other filters of the request, which is what the options of a selection of it are labelled with.

Request​

Responses​

One page of the matching alarms, with the counts of the whole result