> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ansio.trade/llms.txt
> Use this file to discover all available pages before exploring further.

# Alert timing and delivery

> See how often ANSIO sends alerts, set personal reminder intervals and schedules, and diagnose missing or repeated Telegram notifications.

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:

| Your effective severity | Default repeat interval |
| - | - |
| Critical | 10 minutes |
| High | 20 minutes |
| Medium | 60 minutes |
| Low | 60 minutes |
| Off | No delivery for that recipient and rule. |

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.

![Telegram delivery schedule with weekdays, start and end times and Europe Madrid timezone.](https://mintcdn.com/ansio/TbUlSsAFRzZei_af/images/docs/schedule.jpg?fit=max\&auto=format\&n=TbUlSsAFRzZei_af\&q=85\&s=f0e8f7ea2f8c5649be818fcf7d7e6871)

The delivery schedule in ANSIO, shown with a demonstration recipient.

| Control | Meaning |
| - | - |
| Always on | Delivery is allowed throughout the day. |
| Scheduled | Delivery is allowed on selected days and within the selected hours. |
| Starts at / Ends at | The recipient's notification window. |
| Time zone | The zone used for that window, including daylight-saving changes. |
| Vacation or temporary pause | Suppresses delivery until the selected end time. |

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:

**1. Find the incident in Alerts**

Confirm the client and pair, remove restrictive filters, and see whether the condition has reached its Waits period. Not every temporary error becomes an alert.

**2. Read the recipient state**

The recipient must be connected, enabled and authorized for internal alerts. Client read-only access does not receive the internal Manager alert feed.

**3. Read that recipient's rule**

Off suppresses delivery. A personal severity or reminder value may differ from another manager's settings.

**4. Read the timing controls**

Look for an incident snooze, a delivery window, a timezone difference or a vacation pause.

**5. Read delivery health**

Look for a Telegram delivery failure or connection issue. After correcting it, the owner can use Send test to verify the destination.

## 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](https://docs.ansio.trade/alerts/rules.md) · [Telegram access and controls](https://docs.ansio.trade/telegram/controls.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.