Incidents zijn geclusterde foutfamilies. Health Watch groepeert herhaalde events via een fingerprint, zodat je niet tientallen bijna identieke regels hoeft te lezen. Een incident blijft zichtbaar totdat je het zelf op resolved, acknowledged of suppressed zet.

De nuttigste werkwijze is meestal: eerst op tijdvenster filteren, daarna op source of user id, en pas daarna individuele events openen. Voor complexe gevallen geven request trace en gebruikerstijdlijn meestal sneller diagnostisch overzicht dan een losse eventregel.

Warnings zijn niet automatisch defects. Een event zoals request_slow betekent alleen dat een request boven de ingestelde traagheidsdrempel uitkwam. Bij documentverwerking of zwaardere analyseflows kan dat inhoudelijk acceptabel zijn, ook al wil je het operationeel wel blijven volgen.

De knop resolve gefilterde incidents werkt uitsluitend op de huidige incidentfilterset. Dat is bewust zo ingericht, zodat je eerst gericht kunt inzoomen op bijvoorbeeld oude testfouten, één route, één bron of één gebruiker, en daarna alleen dat deel kunt opschonen.

Historische incidents verdwijnen niet vanzelf uit beeld. Daardoor blijft een verstoring ook na herstel nog zichtbaar totdat jij expliciet beslist dat die episode administratief gesloten mag worden. Dat maakt Health Watch geschikter voor forensisch terugkijken, maar betekent ook dat periodieke opschoning zinvol is.