Sparse, exactly as it reads: only the fields you send are written and everything omitted keeps its stored value — including priority. Nothing in this body is required, because the rule being written is already named by its UUID in the path. Creating a rule is the one case that needs more, and it has its own schema: GroupNotificationSettingCreateRequest.
The four limits below — the quiet window, the schedule grid, the gap and the daily cap — mean exactly what they mean on a recipient rule and are enforced by the same code; they simply apply to whichever member this rule governs. Their hours are read on the platform clock, Europe/Kyiv. Defaults, though, are not the same as the recipient rule's in two places, and each field says so where it differs.
Being over a limit does not postpone an alert indefinitely, and for two of the four it does not postpone it at all. A quiet window and a min_interval_minutes gap name the moment they end, so the alert waits and is delivered then — provided that moment falls inside the hour a send is retried for. Beyond that hour, and for the daily cap (which ends at midnight, almost always further off than an hour), the alert ends cancelled: it carries blocked_reason and the time it would have become allowed, and nobody re-sends it. An hour outside schedule_grid names no moment to wait for at all, so that one does not wait even briefly — it ends failed. Read the two statuses as they are meant: cancelled is the platform declining to page on your instructions, failed is a delivery that did not happen.
Only the first page is subject to any of this. Escalation steps, the owner fallback and test alerts bypass all four checks by design — an escalation that went quiet during quiet hours would be an escalation chain running with nobody at the end of it. So a quiet window mutes the opening page and nothing that follows it.