Documentation

Alerts & Notifications

Astral separates user-created market alerts, deployed-strategy signals, order events, and product notifications. They can appear in the same notification surfaces but have different causes and controls.

Manual market alerts

Create alerts from the Terminal Alerts panel or a supported chart/watchlist context. Alerts can monitor simple price or volume sources and technical or custom expressions.

Setting	Behavior
Timing	Intrabar for eligible simple price alerts, or bar close for indicator and custom conditions.
Frequency	Only once, every time after reset, or once per bar close.
Expiration	Session, next session, week, month, custom time, or the maximum open-ended window shown by the UI. The backend caps effective expiry at 30 days.
Delivery	Toast/WebSocket, email, SMS, or push according to the selected profile and account access.
State	Active, inactive, triggered, or expired; alerts can also be muted.

Review the stored condition description and expression in alert details. Editing delivery, profile, expiry, or mute state does not silently rewrite the underlying trigger.

Notification profiles

Profiles group delivery settings for email, SMS, app push, and toast/web push. Email and phone destinations can require verification. SMS access is plan-gated; individual channels can also be unavailable by account or rollout.

Profiles are reusable by strategy deployment, manual alerts, and conditional-order flows where offered. Changing a profile can affect future delivery for workflows using that profile.

Other notification sources

Generated when an active notifications-only, paper, or connected deployment reaches reportable strategy state.

Lifecycle and risk events such as submission, acceptance, rejection, fill, cancellation, pause, or account-integrity issues.

Account prompts, announcements, access changes, and other application-level events.

A focused in-app presentation can surface a newly fired market alert with its original context.

Troubleshooting delivery

Confirm the alert or deployment is active, its expiration has not passed, the condition actually fired at the configured timing, the profile has an enabled channel, and the destination is verified. Browser and operating-system notification permissions can also affect push or toast behavior.

Designing an alert condition

Begin with the market observation, then define its timing. “Price above 200” is incomplete until you decide which price source, whether it can trigger intrabar, how it resets, and when it expires. Indicator conditions generally depend on completed bars because their values can change while a bar forms.

Use only once for a one-time event. Use a resetting frequency when you want a new event after the condition becomes false and later true again. Use once per bar close when repeated intrabar changes would create noise.

Alert lifecycle

The alert is created with a stored expression, timing, frequency, expiration, and profile.
While active, the evaluation service checks eligible incoming data.
A matching evaluation creates a fire event and updates alert state according to frequency.
Delivery services attempt the channels enabled in the selected profile.
Expired, muted, deleted, or inactive alerts no longer behave like active monitoring rules.

The evaluation event and each delivery attempt are distinct. An email problem does not necessarily mean the alert failed to evaluate, and a visible toast does not prove an SMS was delivered.

Profiles and operational changes

Give profiles names that describe their purpose, such as “Trading hours” or “Email only,” rather than a specific alert. Before editing a reused profile, consider every alert or deployment that references it. Disabling a channel can change future delivery across those workflows.

Phone or email verification establishes a destination; it does not override plan access, browser permission, carrier filtering, an expired alert, or a muted profile.

Investigating a missing notification

The condition may not have firedConfirm source, interval, timing, and expression first.

Compare the stored expression with the actual data at the configured evaluation time. An intrabar high crossing a level is different from a close finishing above it.

The alert may not be activeExpiration, mute, frequency, or deletion can stop future events.

Open alert details and inspect state, expiration, last trigger, frequency, and mute controls.

The channel may be unavailableVerification and permissions are channel-specific.

Check the selected profile, verified destination, browser or OS permission, account entitlement, and spam or carrier filtering.

The event may be another notification typeManual alerts, strategy signals, and order events have different sources.

Open the event details and identify its originating alert, strategy, order, or product workflow before changing the manual alert.

Avoiding alert fatigue

Prefer a small number of precise conditions over many overlapping alerts. Delete or deactivate obsolete rules, use expiration for event-specific research, and choose a frequency that matches the decision cadence. If an alert does not change what you would do, it probably should not interrupt you.