Skip to main content
Not every alert needs to wake you up. Quiet hours define a daily local-time window during which a rule’s firings are held rather than delivered — and folded into a single digest-style message once the window ends, so nothing is silently dropped.

​
1. Set the window

Quiet hours take three fields together — start, end, and an IANA timezone — expressed as minutes since local midnight (0–1439):
curl
curl -H "Authorization: Bearer $ALTERSCOPE_API_KEY" \
     -H "Content-Type: application/json" \
     -X PUT -d '{
       "quiet_hours_start_min": 1320,
       "quiet_hours_end_min": 420,
       "quiet_hours_tz": "America/New_York"
     }' \
  "https://api.alterscope.org/v1/alerts/rules/$RULE_ID"
1320 is 22:00, 420 is 07:00 — this rule goes quiet at 10pm and resumes at 7am, both in America/New_York. Because start (1320) is greater than end (420), the window wraps past midnight; if start were less than end it would be a same-day window instead (e.g. 540→1020 for 9am–5pm quiet hours).
python
client.put(f"/v1/alerts/rules/{rule_id}", json={
    "quiet_hours_start_min": 22 * 60,
    "quiet_hours_end_min": 7 * 60,
    "quiet_hours_tz": "America/New_York",
})
All three fields are required together — sending only quiet_hours_start_min returns 400 (quiet hours require start, end, and tz). To clear quiet hours entirely, you currently have to recreate the rule without them; there’s no dedicated “unset” shorthand.

​
2. What happens to a fire inside the window

A condition match that would normally fire immediately is instead held — not discarded — for delivery once the window ends. Non-critical fires are the ones affected; the point of quiet hours is to stop non-urgent noise overnight, not to hide something you’d want to act on regardless of the hour. You can see a held fire on the event log while it’s waiting:
curl
curl -H "Authorization: Bearer $ALTERSCOPE_API_KEY" \
  "https://api.alterscope.org/v1/alerts/events?rule_id=$RULE_ID&status=suppressed"
Once the window closes, the held fire is delivered folded into a batched message alongside anything else that queued up during the same window — you get one notification summarizing the quiet period instead of one per fire.

​
3. Timezone validation

quiet_hours_tz is checked against the IANA timezone database at write time — an invalid zone name is rejected immediately with 400, rather than silently failing to ever engage:
curl
curl -H "Authorization: Bearer $ALTERSCOPE_API_KEY" \
     -H "Content-Type: application/json" \
     -X PUT -d '{
       "quiet_hours_start_min": 1320,
       "quiet_hours_end_min": 420,
       "quiet_hours_tz": "Eastern"
     }' \
  "https://api.alterscope.org/v1/alerts/rules/$RULE_ID"
# 400: quiet_hours_tz is not a valid IANA timezone
Use full IANA names (America/New_York, Europe/London, UTC), not abbreviations or offsets.

​
Troubleshooting

  • 400: quiet hours require start, end, and tz: partial-merge PUT still requires all three quiet-hours fields in the same request the first time they’re set — you can’t add quiet_hours_tz alone to a rule that has no start/end yet.
  • Alert arrived outside the window when I expected it deferred: quiet hours suppress non-critical fires; a rule’s severity is assigned by the platform based on its data source and conditions, not a field you set directly.
  • Window seems inverted: start > end means an overnight window (wraps past midnight); start < end means same-day. start == end disables quiet hours entirely for that rule (treated as no window).
  • Nothing showed up after the window ended: confirm the fire is actually recorded — GET /v1/alerts/events?rule_id=$RULE_ID&status=suppressed — and check your channel’s delivery status once the digest goes out, same as any other fire (see Troubleshooting in the rules guide).