Aglet

Triage quiet-hours expectations before changing delivery timing

Quiet hours can delay an interruption while the underlying event remains available. Triage the timing promise before changing schedules. Capture the event timestamp, user time zone, urgency, delivery attempt, and in-app state so delayed delivery is not mistaken for a lost event.

Establish what is happening

  1. Capture one delayed event

    Record event creation, user schedule, time zone, urgency, channel, delivery attempt, and in-app visibility. Include an event inside and outside the quiet window. Keep the current clock and daylight or travel context visible.

  2. Compare timing promises

    Ask what the settings promise: no interruption, deferred alert, or no event. Compare in-app availability with external delivery and check whether labels explain the distinction. Mark platform summary or focus behavior as an external boundary.

  3. Set a quiet-hours boundary

    State which events delay, which remain available, when delivery resumes, and how a person can review the event now. Preserve a normal-hours control. Stop when another reviewer can explain the delay without calling it delivery loss.

What to carry forward

The triage output is a quiet-hours contract with timestamps, urgency, channel, and visibility states. Stop when delayed interruption and missing event are distinguishable. If time zone or platform behavior is unknown, keep the result provisional and record the missing observation.

Technical background: Android developer documentation.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow