The interval mismatch is arithmetic. Put a one-minute alarm interval on a metric that emits hourly and you get 60 evaluation windows an hour, 59 of which contain no new data point [16]. Oracle's documented symptom is an alarm that fires and then clears at the next interval even though the last data point exceeded the threshold [3]. The alarm is behaving correctly on the data it can see. It is asking for data at a rhythm the metric cannot supply [4]. The stated fix is to read the metric's documented emission frequency and set the interval to match or exceed it [5], which presumes the frequency is written down somewhere you can check, and the validation list accepts metric documentation or a chart review as the evidence [18].
Dimensions fail in the other direction. The query is valid and returns a healthy stream, just not for the resource you meant. Filter on the wrong compartment, availability domain, resource ID or pool and the alarm sits in OK while the real resource degrades [7]. The ordering in the source is the part worth copying: confirm scope before touching thresholds, because a precise threshold on the wrong resource buys nothing [8]. Threshold tuning is the enjoyable part, which is presumably why it gets done first.
Absence alarms are where the documented semantics earn their keep. Oracle's `absent()` returns 1 while the metric is missing for the entire interval and 0 when it is present [9]. After continuous true values across the configured absence detection period, the statistic stops returning values [10]. The default period is two hours, configurable from one minute through three days [11], a range of 4320 to 1 measured in minutes, with the default sitting 120 times above the floor [17]. On that documented behaviour, an escalation path slower than the period you chose can outlast the true values it depends on. That is a question about your escalation clock as much as about the alarm.
The `groupBy` recommendation is the detail I would not have guessed. Oracle advises including it in absence queries because a dimension OCI introduces later can create an initially empty metric stream, and an empty stream reads as absent even while every other stream reports [12]. The example query pins `resourceId` in the filter and then groups by it [13]. That is a query hardened against the platform's own future schema changes, and it is good craft to write the reason down next to it.
The notification check is the cheapest one and the most likely to be waved through. An alarm can point at the correct topic and deliver nothing, which is why the list keeps "topic is the intended one", "subscription is confirmed" and "test alarm or controlled trigger was received" as separate lines [15]. Those are three states of the same path. The received test message is the one that counts as evidence [14].
For any of this to transfer to your estate, two things have to hold: the metrics you alarm on need a published emission frequency you can look up, and you need permission to run a controlled trigger where it counts, since the source asks for a controlled absence test where safe plus alarm history showing the expected transition [19]. The list is short enough to run in an afternoon, and what it produces is a record rather than an assertion [1].
