Alert timing and delivery

There are three separate clocks: how often ANSIO evaluates a condition, how long that condition must persist, and how often you receive reminders.

​

First notification

Server monitoring runs about once a minute. A rule’s Waits period starts when the condition is detected. For example, Futures quotes blocked has a two-minute wait. If the block is first observed at 10:00 and persists, it becomes eligible around 10:02. Delivery can be later because of polling, schedules or a delivery retry. No extra wait means the rule does not add a persistence delay. It does not mean a message is sent on every exchange tick.

​

Default reminders

After the first notification, the usual defaults are: These repeats apply while the condition remains active and delivery is allowed. They do not create a new incident each time. A severity escalation can notify sooner than the ordinary repeat interval. DEX sale notifications are event-based and do not repeat an old sale.

​

Change your rule preferences

Open Alerts → Telegram and choose Rules on the intended recipient.

• Severity changes that recipient’s priority for the rule, or turns its delivery Off.
• Reminds sets the personal repeat interval in minutes.
• 0 means one initial notification and no ordinary repeats.
• A custom value can be 0–10,080 minutes.
• An explicit custom interval remains in effect if the severity changes. Without one, the default follows the effective severity.

The owner can assign a recipient to an active team user. That assigned user can manage their own preferences. Selecting a different recipient changes whose settings you are editing.

​

Delivery schedule

Open Schedule on the recipient. All severities respect the schedule, including Critical. An overnight shift ends on the following day. For example, Monday 22:00–06:00 runs from Monday evening to Tuesday morning. The selected day is the start day. Equal start and end times are not a 24-hour schedule; choose Always on for that. When a shift starts, only alerts that are still active are sent. An incident that started and resolved while delivery was off does not become an old-message backlog. The schedule affects notifications. Bots and server monitoring continue to run.

​

No message arrived

Work from the incident toward the recipient:

​

The same message keeps arriving

Compare its client, pair, rule and first-seen time. It may be a reminder for the same active incident rather than a new failure. Acknowledge records that you saw it. Use Snooze for a temporary pause, or change Reminds for that recipient and rule. The condition remains visible until it clears. Separate accounts can produce similar messages. Venue-level failures are grouped by venue, while account rules stay separate.

​

The desk shows Resolved, but Telegram does not

The recipient must have received that same alert episode before it can receive its resolved message. Delivery schedules and preferences can also suppress the message. The desk’s current state is the reference; an old Telegram message is a record of what was known at that time. Rule reference · Telegram access and controls