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.
In the desktop Terminal, the square top-bar bell beside the cash and account controls opens a compact, scrollable popover. Each row shows the event, its description and timestamp; hover the timestamp for the full time, or select the row to open its source. Hover or focus a dismissible row to reveal Remove notification. The header's Clear All control asks for confirmation. Persistent account notices cannot be individually dismissed.
On mobile web, Notifications opens the signed-in account's notification feed. Search notifications filters loaded events. The collapsible Unread group contains unread events; All contains read events. Open a row to inspect its details in a sheet. Notification actions → Mark all read updates the requested unread events only after the server confirms success; a failure shows an error and leaves the unread state unchanged. New arrivals are not silently included in an earlier request. Clear all asks for confirmation and retains persistent account notices.
The page uses the existing account event source. A navigation dot, notification title or read acknowledgement does not establish that a trade filled or change account mode. Check the event details and actual order status.
Clear notifications
On desktop and mobile web, use the notification list's dismiss control for one event, or Clear all and confirm. Events stay visible until the server accepts the request. If you see Notifications weren't cleared, check your connection and try again; the failed request does not remove the events from the list. An older background refresh should not bring successfully cleared events back.
Persistent account notices remain until their underlying condition is addressed. Clearing a notification does not stop a strategy, cancel an order, or disable an alert. New events can still arrive. Installed native clients can differ by release.
Manual market alerts
Create alerts from the Alerts panel or a supported chart/watchlist context. The mobile hamburger menu follows the native menu and has no Alerts row; use supported chart/watchlist alert controls or Chat’s reviewed alert flow. You can also ask in Chat, for example “Alert me when this token crosses above [price] on a 15-minute close”; the agent presents an alert proposal for your confirmation.
- Open the create-alert form and select the exact asset.
- Choose the condition's source, comparison and value. Use Add condition and the AND/OR control for additional conditions. For a custom condition, enter its plain-language description and inspect the generated expression.
- Choose the offered trigger timing and Interval. Simple price alerts can support intrabar checks; indicator/custom conditions use their supported bar-close timing.
- Set frequency and Expiration, give the Alert name, and choose a profile under Notifications. Create new profile opens profile setup when offered.
- Review the condition and delivery, then choose the form's Create action. For an existing alert, Save applies edits. Confirm the alert appears with the intended state in the list.
- Open an alert's details to inspect its condition, expiration and last trigger, or use the offered edit, mute, deactivate or delete actions. Muting delivery and deleting a rule are different operations.
Creating an alert does not place an order. If the UI cannot represent the desired condition, ask the agent to check support rather than replacing it with a different trigger.
Alerts can be set on tokens from any network Astral charts, including Base, Robinhood Chain and Arbitrum tokens whose orders the assistant can't set up; for those it offers an alert at your levels instead (details). Alert conditions use price, not market cap. Ask the assistant for an alert at a market cap and it converts that to a price from the token's current market cap and price and states the assumption, for example "$1.4M market cap ≈ $0.0014 per token while supply stays about 1.0B". The alert still fires on that price if the supply later changes.
| 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. |
Alert conditions use the same formula functions as chart indicators. Clock functions such as HOUR() use New York time (America/New_York, with daylight saving), while strategies use their engine timezone, UTC by default; see time zones of clock functions. When you ask the assistant for an alert, it checks that the condition is a formula alerts accept and uses bar-close timing for anything other than a simple price level.
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.
Set default channels and read notifications
- Open Settings → Notifications.
- Choose the default Email, SMS, App push and Toast channels that are available. The current SMS control says Premium · verified number required; verify the phone in Settings → Profile and check actual account eligibility.
- App push targets signed-in mobile devices. Toasts appear while Astral is open. Browser/OS permission can still prevent delivery; email is sent to the account email.
- Open the bell's Notifications list (mobile: the bottom Notifications tab) to read events. Follow an event's link to its strategy, order or source for the actual current state. Use read/clear controls where offered to manage the notification list.
Default channels and a particular alert's selected profile can differ. Check both when diagnosing missing delivery.
Strategy price-feed warnings
Waiting for this token's price feed on an Onchain strategy is an in-app warning when automatic recovery is pending and no held position is affected for that token. Neither that warning nor its matching recovery sends email or SMS. Critical alerts remain possible when protection for a held position is affected, holdings are unknown, or an operator must act; configured channel access still applies.
Check the event time and the affected deployment under Strategies → Deployed. Old events can retain their original critical label. Clearing one does not repair the feed or change trading readiness. See Price-feed warnings and recovery for what to do, Paper/Real money boundaries and desktop/mobile behavior.
Other notification sources
Strategy signals
Orders and trading
Product notifications
Triggered alert modal
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.
The alert may not be activeExpiration, mute, frequency, or deletion can stop future events.
The channel may be unavailableVerification and permissions are channel-specific.
The event may be another notification typeManual alerts, strategy signals, and order events have different sources.
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.