Automations
Configure reusable schedules that create notifications.
An automation is a reusable schedule, notification message, and delivery
policy. Anchor runs the schedule and creates one notification for each due
execution.
When another application already knows that something happened, it should
create a complete notification directly with POST /v1/notifications instead
of creating a reusable resource first.
Pausing an automation prevents it from creating future notifications. Existing
active notifications continue until they reach a terminal state.
Schedules
Automation schedules use the home timezone configured in Settings. Anchor
evaluates recurring schedules with daylight-saving transitions in mind and
records the scheduled time for each notification.
Anchor’s quiet period delays Routine and Important delivery. It does not silently discard a notification.
Anchor and Pushover quiet periods
The two settings act at different stages:
| Setting | What happens during the configured period |
|---|---|
| Anchor quiet period | Anchor does not send Routine or Important notifications yet. It waits until the period ends, subject to the notification deadline. Emergency bypasses this restriction. |
| Pushover quiet hours | Pushover receives the notification immediately. Routine is presented silently, while Important and Emergency can bypass Pushover quiet hours. |
For example, consider an Important notification due at 2:00 AM while both systems are configured for 10:00 PM–7:00 AM:
- With only Pushover quiet hours, Anchor sends it at 2:00 AM and Important bypasses those hours.
- With Anchor’s quiet period enabled, Anchor waits and sends it at 7:00 AM.
- If waiting until 7:00 AM would exceed the notification deadline, Anchor marks it Missed instead.
- Emergency is sent immediately regardless of Anchor’s quiet period.
Disable Anchor’s quiet period and use Pushover quiet hours when notifications should arrive immediately but ordinary alerts may be silent. Enable Anchor’s quiet period when overnight Routine and Important notifications should wait until morning. You only need both when Pushover quiet hours must also govern messages from other applications or the two periods intentionally use different schedules.
Manual triggers and external schedules
Trigger now creates a real test notification through the same durable
workflow used by scheduled executions. API keys use anchor:manage for this
operation.
External applications that want Anchor to own a schedule can create and manage
an automation with anchor:manage. Applications that already own timing create
notifications directly with notifications:create.
Duplicate an automation when you want a new independently editable definition
with the same starting configuration.
Completing an upcoming run early
An Active Automation that requires completion can have its exact next scheduled run marked complete before it is due.
Use the check action in Upcoming scheduled, the Automation table menu, or the Automation detail page.
Anchor records a Completed early Notification in history without sending a delivery.
A recurring Automation advances to its following scheduled run, while a one-time Automation ends.
The action is unavailable after the run starts or while the same Automation already has an unresolved Notification.
Gradual urgency
Automations that require acknowledgement or completion can increase urgency in
independent stages. A threshold is inclusive: “Important starts with
notification #2” means the second Anchor-created notification is Important.
For example, a ten-minute repeat interval with Important at #2, Emergency at
#4, and a limit of four notifications produces:
| Notification | Urgency |
|---|---|
| #1 | Routine |
| #2 | Important |
| #3 | Important |
| #4 | Emergency |
Anchor then stops creating delivery cycles. The final Emergency cycle may still
repeat inside Pushover for up to 30 minutes; those provider-managed alerts do
not increase Anchor’s notification count.
Routine-to-Emergency escalation always passes through Important.
Important must start before Emergency, and Emergency cannot start after the configured notification limit.
Snoozing pauses the current escalation step and replays it at the selected time with the same urgency.
That explicit replay bypasses Anchor quiet hours and the Automation delivery window, does not consume another escalation step, and may be repeated at the final step.
If the replay is ignored, normal escalation continues or the Notification becomes Missed after its final step.
A fixed deadline still wins.
Acknowledging or completing the notification stops the remaining cycles according to its response behavior.
The Automation form previews the next no-action sequence, including quiet-hour delays, delivery windows, deadline truncation, urgency transitions, and the final Anchor delivery.
User-requested Snooze replays are not included in that preview.
Account defaults start Important at #10, Emergency at #20, and stop after #20 unless the Automation overrides them.
The maximum limits unattended automatic escalation, not explicit Snooze replays.
“Stop trying after” is a fixed deadline for each Notification. Snoozing may
postpone the next delivery only to a time before that deadline; it does not
extend or restart the deadline.