Alerts

An alert is a problem AISA found and that you need to look at. There are six families:

• Tag missing, a critical alert on one site. AISA opens it when the tag that was on your homepage is gone, because the assistant does not show on a page without it.
• Widget not showing, a warning on one inline widget. AISA opens it when a button or Starters widget could not find its place on the page for too many shoppers. See Widget alerts.
• Engagement fell, a warning on one widget. AISA opens it when far fewer of the shoppers who see the widget open the conversation from it than in the weeks before. See Engagement alerts.
• Test paused, a warning on one widget's A/B test. AISA opens it when a safety check pauses the test. See Test alerts.
• Orders fell and Orders stopped, two warnings on one site. AISA opens them when a site's orders drop well below their usual level, or stop. See Orders alerts.
• Connector not answering, a critical alert on one connector. AISA opens it when a connector that a live agent uses failed two checks in a row, so the assistant answers shoppers without its tools. See Connector alerts.
• Quota alerts, one per monthly quota: Conversations quota, Pages read quota and Generations quota. They concern the whole organization, not a site. See Quota alerts.

You can't dismiss an alert, and you don't need to. AISA closes it when the problem clears.

What opens a tag alertCopy Anchor Link

Every hour, AISA loads each site's homepage and looks for the site key. An alert opens only when all of these hold:

• The tag was seen on that site at least once before.
• The check found a readable page without the key, and a second load a few seconds later found none either.
• Monitor the tag is on for the site.
• The site has no alert open already. A long outage is one alert, not one per hour.

A page AISA cannot read opens nothing. If your firewall refuses the request, or the site shows a password page or a bot check, the Tag detection card says Cannot verify and no alert opens. A site that never had the tag opens none either.

What closes a tag alertCopy Anchor Link

• The tag is back. A check finds the key again. The alert closes at that check. It can take up to an hour, or use Check now on the Installation tab.
• Monitoring is turned off. Switching Monitor the tag off for the site closes its open alert.

If the tag goes missing again later, a new alert opens. The old one stays in the history.

Widget alertsCopy Anchor Link

An inline widget appears at a mount point on your page. When the tag cannot find that spot, the widget does not render and the shopper sees nothing. A widget alert tells you this is happening on a share of your traffic, not just on the one page you checked.

When one opens

Every hour, AISA looks at each switched-on button and Starters widget of your sites over the last 24 hours. It counts the shopper sessions in which the widget's live version loaded, and among them the sessions in which it could not find its mount point at least once. An alert opens when:

• the widget had at least 100 such sessions, and
• it could not find its place in more than 10% of them.

Chat bubbles and question bars never open one: they float over the page and have no mount point to miss. When the widget runs an A/B test, only its live version is counted, not the candidate. Each widget has its own alert, so two widgets of one site can each have one open. While the problem lasts, it stays one alert, not one per hour.

When one closes

• The widget shows again. A check finds that it missed its place in 4% of its sessions or fewer, over at least 100 sessions. Between 4% and 10% an open alert stays open, so a widget near the limit does not open and close every hour.
• The widget is switched off. A switched-off widget appears nowhere, so its alert closes at once.
• The widget is deleted. The alert closes and stays in the history under the widget's name.

With fewer than 100 sessions in the last 24 hours, a check changes nothing: no alert opens, and an open one stays open until there is enough traffic to tell.

Where to fix it

Open the widget from the alert and check the Placement on the page card on its Placement tab. A theme update or a page redesign often moves or removes the element the widget is placed on. When the mount doesn't resolve lists what to look at, and the Engagement report lists every widget that failed to mount.

Engagement alertsCopy Anchor Link

A widget can load and show correctly and still stop doing its job: a redesign, a new banner or a slower page can push it out of sight or out of mind. An engagement alert tells you that the share of shoppers who open the conversation from the widget has dropped well below its usual level. It uses the engagement rate: the sessions that saw the widget and opened the conversation from it, over the sessions that saw it.

When one opens

Once a day, shortly after 00:07 UTC, AISA reads each switched-on widget of your live sites over four periods of 7 complete UTC days: the last 7 days, and the 3 weeks before them. An alert opens when all of these hold:

• the widget was seen in at least 200 sessions in each of the 4 periods,
• the engagement rate of the last 7 days is at or under half of the usual rate, which is the median of the 3 weeks before, and
• no member changed the widget and no test ran on it in any of the 4 periods.

A change is switching the widget on or off, or publishing a version. A test counts from its start to its end, or while it still runs. A widget in that situation is not judged until the change is more than 4 weeks old, because its rate would say nothing about its usual level. A widget with too few sessions in any period is not judged either. AISA reads which weeks a member changed the widget from Admin activity. An organization whose retention window is shorter than 29 days therefore gets no new engagement alert, because an old publish could look like a spontaneous fall. The window is 365 days by default and is not a setting in the dashboard. An alert that is already open can still close. Every version of the widget counts together. Each widget has its own alert, and it stays one alert while the fall lasts.

When one closes

• Engagement is back. A later daily check finds that the last 7 days were back to the level the alert opened against, over at least 200 sessions and with no change or test in that period. The level is the usual rate at the time the alert opened. AISA keeps it and never shows it, and does not recompute it over the weeks of the fall.
• The widget is switched off. The alert closes at once.
• The widget is deleted. The alert closes and stays in the history under the widget's name.

An open alert closes only on a week with no member change and no test on the widget, so after you fix a problem it can stay open for a week or two. A check that finds too few sessions closes nothing either.

Where to look

Open the widget from the alert and read its Performance tab. Then check what changed on your site around the time the rate fell.

Test alertsCopy Anchor Link

When an A/B test runs, shoppers are split between the live version and a candidate. A safety check can end it on its own and send every shopper back to the live version (see When a test stops itself). A test alert tells you that happened, because nobody was there to see it.

When one opens

Only when the test is ended by a safety check. That covers the candidate failing to load more than the live version, shoppers abandoning more after opening the chat, and a split that drifts from the one you configured. It never opens when:

• a member stops the test, or keeps the champion,
• a member promotes the candidate,
• the widget is switched off, or
• the widget is deleted.

You did those yourself, so there is nothing to tell you. Each test opens at most one alert, a Test paused warning. The alert opens at the moment of the pause. If it cannot be opened, the pause still stands, no alert shows and the error is only logged.

When one closes

• A new test starts on the widget. The alert closes with "A new test started on the widget."
• The widget is deleted. The alert closes and stays in the history under the widget's name.
• 14 days pass. The alert closes with "The alert expired after 14 days." The hourly widget check does this, so it can take up to an hour more.

Nothing else closes it. Switching the widget off, or stopping the test, leaves the alert open until one of the three above.

Where to look

Open the test from the alert. It leads to the widget's Experiment tab, which says what ended the test. Fix what the check found, then start a new test.

Orders alertsCopy Anchor Link

AISA watches the orders of each live site. The usual cause of a sudden drop is a problem on your side: a broken checkout, a payment method that fails, an order feed that stopped. An orders alert tells you early, before you read it in the weekly numbers.

Orders fell

A warning on one site. AISA compares the orders of a complete UTC day, counted as the Sales report counts them (one per order, test orders and cancelled orders left out), with the usual level for that weekday. The usual level is the median of the same weekday over the 8 weeks before. A Tuesday is compared with the 8 Tuesdays before it. The alert opens when:

• the day's orders are under half of that usual level, and
• order events (a purchase, a refund or a cancellation) still arrived that day.

The second condition keeps a day with no order event at all from opening this alert. That case is Orders stopped.

The check runs every hour, but a day is a day: it gives the same answer at every run until the next UTC day, and an open alert closes at the first check after a complete day reaches half of its usual level or more.

Orders stopped

A warning on one site. It opens when no order event arrived for 24 hours on a site whose usual level for that weekday is 5 orders or more. A quieter site never opens it, because a day without an order is normal for it. It closes at the first order event after that. A refund or a cancellation counts as one.

Silent at first

Both alerts stay silent until the site's first order is 8 weeks old. Before that there is not enough history to know what a usual day looks like. A site with no order never opens one. Days are UTC days, so "a complete day" ends at 00:00 UTC, whatever your time zone.

What the alert cannot tell you

It sees that orders fell or stopped. It cannot tell a broken checkout from a broken order feed. If your store takes orders but does not send them to iAdvize, the alert looks the same as a store that sells nothing. Place a test order on your site, then check that your store still sends its orders to iAdvize (see Shopify order webhooks).

A quiet day is not always a problem either. A holiday, the end of a campaign or a stock-out can halve a day's orders. The alert asks you to look, it does not say something is broken.

When one closes

• Orders are back. The alert closes with "Orders are back to the usual level." It closes on its own, at a check.
• The site is deleted. It closes with "The site was deleted."

Where to look

The alert has an Open the Sales report button that leads to the site's Sales report. Read the day there, then look for a change that started that day: checkout, payment methods, delivery options or a campaign.

Connector alertsCopy Anchor Link

A connector gives the assistant tools such as a catalog search. When the connector's server stops answering, the assistant keeps talking to shoppers but cannot use those tools. A connector alert tells you before a shopper does.

When one opens

Every hour, AISA calls each connector that matters and records whether it answered. It opens an alert when:

• the connector failed two checks in a row, and
• a live agent uses it: the connector is linked to the live version of the agent the site serves, and
• its site is not deleted.

A check connects to the connector's endpoints and lists their tools. For a Shopify or Adobe Commerce connector it also makes one catalog request. It stores nothing of the answer and changes nothing on the connector. A check that Check now runs counts like an hourly one, so two failed clicks in a row also open the alert. While the problem lasts, it stays one alert, not one per hour. Each connector has its own alert.

A connector that no live agent uses is not checked every hour and never opens an alert. You can still run Check now on it, and the outcome shows on its page.

When one closes

• The connector answers again. The first check that succeeds closes the alert. It can take up to an hour, or use Check now on the connector's page.
• No live agent uses it any more. The site's agent switched to a version that does not link the connector, the site has no agent, or the agent was deleted. The next hourly run closes the alert.
• The connector is deleted. The alert closes at once and stays in the history under the connector's name.

Check now

Open the connector from Connectors in the site's workspace. The Connection card shows when AISA last called the connector and when it last answered ("Never" until it has). The Check now button calls the connector once and says whether it answered. You need the Connectors: Edit permission to see the button. A connector can be checked once a minute: a second click inside that minute says how many seconds to wait, and the connector is not called. A check from the button changes no setting and records no entry in Admin activity.

Where to fix it

Open the connector from the alert. Check that the store is online and that the connector's address and access token are still valid. The connectors guide covers each platform's settings.

Quota alertsCopy Anchor Link

AISA keeps one alert per quota. Usage is counted per calendar month (UTC) against the quotas on the Billing page.

When one opens

• Warning: the month's usage reaches 80% of the quota, rounded up. With a quota of 1,001 units, the alert opens at 801.
• Critical: usage reaches the quota and reaching it stops the service. The alert starts as a warning and becomes critical at that point.
• A quota of 0 never opens an alert.

When usage reaches the quota but nothing stops, the alert stays a warning.

When one closes

• The quota is raised. The alert closes as soon as the change is saved, or moves back to a warning if usage is still past 80%.
• A new month starts. Usage restarts at zero at 00:00 UTC on the 1st. The alert closes in the first minutes after that. If the new month is already past 80%, a new alert opens.
• Usage falls back under 80%. This is rare, since usage only goes up. A unit given back after a failed call does not close an alert by itself. The alert is re-checked at the next quota change, the next booking that reaches a threshold or the next new month.

Each closed alert stays in the history with the reason: "The quota was raised.", "A new month started." or "Usage is back under the threshold."

Quota alerts send no email of their own. The quota emails at 80% and 100% are separate.

When a site is deletedCopy Anchor Link

Deleting a site closes all of its open alerts, tag, widget, engagement, test, connector and orders alerts alike, with "The site was deleted." They are not erased: they stay on the Resolved tab.

Who is toldCopy Anchor Link

Alert emails go to every active member of the organization whose role is the built-in Admin role, in each admin's saved language. Members with any other role, a custom role included, do not get them.

Tag alerts. One email per alert.

• At most one email per site in any 24 hours. If a tag goes missing, comes back and goes missing again within a day, the second alert opens in the dashboard but sends no email.

Widget alerts. One email per hourly check, listing every widget alert that check opened in your organization, grouped by site.

• Each site shows its name and address. Under it, each widget shows its name, that it could not find its place on the page for many shoppers, when the alert opened (in the admin's saved time zone, or UTC) and an Open the widget link.
• The email ends with what usually causes it (a theme update or a page redesign) and says that each alert closes by itself.
• It carries no figure: no share, no session count. The dashboard is where you look at the widget.
• At most one email per widget in any 24 hours. A widget whose alert closes and opens again within a day gets a new alert in the dashboard but is not listed again.
• A widget deleted before the email goes out is left out of it.

Engagement alerts. One email per day, listing every engagement alert that the daily check announces in your organization, grouped by site.

• The email goes out with the daily check, so it can arrive up to a day after the fall started. Only the production check sends it.
• Each widget shows its name, that far fewer shoppers opened the conversation than usual, when the alert opened and an Open the widget link to the widget's page.
• It carries no figure: no rate, no usual level, no session count. The widget's page is where you read them.
• At most one email per widget in any 24 hours.
• A widget deleted before the email goes out is left out of it.

Test alerts. They go out in the same email as the widget alerts: one email per hourly check, listing every alert that check announces.

• The alert opens at the moment of the pause, but the email goes out with the next hourly check, so it can arrive up to an hour after the pause. Only the production check sends it.
• A test alert shows the site's name and address, the widget's name, that a safety check paused the test, when the alert opened and an Open the test link to the widget's Experiment tab.
• It carries no figure: no rate, no session count and no name of the guardrail that fired.
• At most one email per test in any 24 hours. A test pauses only once, so in practice each paused test is announced once.
• When one check announces several kinds of alert, one email lists them all, with a neutral subject ("2 alerts need your attention") and each kind keeps its own line on what to do.
• A widget deleted before the email goes out is left out of it.

Orders alerts. They go out in the same email as the widget and test alerts: one email per hourly check, listing every alert that check announces.

• An orders alert shows the site's name and address, what happened ("Orders fell well below the usual level." or "No order for 24 hours."), when the alert opened and an Open the Sales report link. It has no widget name, since it concerns the site.
• It carries no figure: no order count, no usual level, no percentage. The Sales report is where you read them.
• At most one email per site and kind in any 24 hours.
• When one check announces several kinds, one email lists them with a neutral subject ("2 alerts need your attention").
• Only the production check sends it, hourly.

Connector alerts. One email per hourly check, listing every connector alert that check opened in your organization, grouped by site. The same email goes out when a Check now opens an alert.

• Each site shows its name and address. Under it, each connector shows its name, that it failed two checks in a row, when the alert opened (in the admin's saved time zone, or UTC) and an Open the connector link.
• The email says to check that the store is online and that the connector's address and access token are still valid, and that the alert closes by itself at the first check that succeeds.
• It carries no failure detail: never the server's error text, an address or a token.
• At most one email per connector in any 24 hours. A connector whose alert closes and opens again within a day gets a new alert in the dashboard but is not listed again.
• A connector deleted before the email goes out is left out of it.

For every alert

• Closing an alert sends nothing.
• Quota alerts send no alert email.

Where you see itCopy Anchor Link

• Sidebar. An Alerts entry at the bottom shows the number of open alerts. The count is red if at least one open alert is critical and amber when all of them are warnings. Its accessible name carries the numbers, so the colour is never the only signal: "Alerts, 3 open", or "Alerts, 3 open, 1 critical" when one is critical. On a narrow screen the same dot, in the same colours, sits on the button that opens the sidebar.
• Banner. While a site has an open tag alert, a red banner sits at the top of its Overview, Widgets and Installation pages. It names the site's address and the time of the check, and links to the Installation tab and to the alert. It has no close button. A widget alert shows no banner.
• Connector banner. While a connector alert is open, a red banner sits at the top of the site's Overview, Widgets and Agents pages: "Connector name is not answering", with "Your assistant answers shoppers without it until the connector answers a check again." and links Open the connector and View the alert. Two failing connectors show two banners. It has no close button and goes when the alert closes.
• Alerts page (/dashboard/alerts). The Open tab lists open alerts, most severe first and then oldest first. Each row shows the site, when it opened, when the tag was last seen and the last check. A quota alert shows Whole organization instead of a site, a Warning or Critical badge, and no tag times. It has a View billing button, shown only to members who may view billing. Other members see the alert without the button. An orders alert reads Orders fell or Orders stopped, with a Warning badge, the site, no tag times and an Open the Sales report button. It closes with "Orders are back to the usual level." An engagement alert reads Engagement fell, with a Warning badge and the line "Far fewer shoppers who see the widget open the conversation than usual." It shows the site and "Widget: " followed by the widget's name, no tag times, and an Open widget button that leads to the widget's page. A test alert reads Test paused, with a Warning badge and the line "A safety check paused the test, so shoppers see the live version again." It shows the site and "Test on: " followed by the widget's name, no tag times, and an Open the test button that leads to the widget's Experiment tab. A connector alert reads Connector not answering, with a Critical badge and the line "The connector failed two checks in a row, so the assistant answers without it." It shows the site and "Connector: " followed by the connector's name, no tag times, and an Open connector button that leads to the connector's page. A widget alert reads Widget not showing, with a Warning badge and the line "On many pages the widget could not find where to appear, so shoppers there do not see it." It shows the site and "Widget: " followed by the widget's name, no tag times, and an Open widget button that leads to the widget's page. The Resolved tab is the history: the most recent 100, with how each closed and how long it lasted. A tag alert closes with "The tag is back on the page" or "Monitoring was turned off for this site". A test alert closes with "A new test started on the widget.", "The widget was deleted." or "The alert expired after 14 days." An engagement alert closes with "Engagement is back to its usual level.", "The widget was switched off." or "The widget was deleted." A widget alert closes with "The widget shows on the page again.", "The widget was switched off.", "The widget no longer sits in the page." or "The widget was deleted.", and a deleted widget keeps its name there. A connector alert closes with "The connector answers again.", "No live assistant uses the connector any more." or "The connector was deleted.", and a deleted connector keeps its name there. Any alert of a deleted site reads "The site was deleted."

Every member can read the Alerts page. No member can dismiss an alert, whatever their permissions.

Over the API and MCPCopy Anchor Link

The alerts list and Check now are also available outside the dashboard:

• REST API: GET /api/v1/alerts lists open or resolved alerts, POST /api/v1/sites/{siteId}/tag-check runs a tag check and POST /api/v1/connectors/{connectorId}/check checks a connector.
• MCP server: the tools list_alerts, check_site_tag and check_connector.

A quota alert has kind quota_conversations, quota_page_reads or quota_generations, a severity of warning or critical, and a resolution of quota_raised, month_rollover or below_threshold once closed. It has no site (siteId, siteName and siteUrl are null) and no tag times. It carries no usage figure, no quota and no cost, so read those on the Billing page.

A widget alert has kind widget_mount_failed and severity warning. It names the widget in subject (type widget, its id and name, the name kept after the widget is deleted); every other alert has subject null. Once closed, its resolution is mount_recovered, widget_disabled, widget_not_inline (its live version became a floating format, or it has no live version any more) or subject_deleted. A connector alert has kind connector_unavailable and severity critical. It names the connector in subject (type connector, its id and name, the name kept after the connector is deleted). Once closed, its resolution is connector_back, connector_unused or subject_deleted. It carries no failure detail and no tag times. Any alert closed by deleting its site has resolution site_deleted. A widget alert carries no share and no session count. Only a tag alert carries lastSeenAt and lastCheckedAt; they are null on every other kind.

A test alert has kind experiment_guardrail_paused and severity warning. Its subject has type experiment, the test's id and a name that is the widget's name (kept after the widget is deleted). The widget's own id is not in the output. Once closed, its resolution is experiment_restarted, subject_deleted or expired. It carries no guardrail name, no rate and no session count.

An engagement alert has kind widget_engagement_fall and severity warning. Its subject has type widget, the widget's id and its name, kept after the widget is deleted. Once closed, its resolution is engagement_recovered, widget_disabled or subject_deleted. It carries no rate, no usual level, no threshold and no session count.

An orders alert has kind orders_fall or orders_stopped and severity warning. It concerns a site (siteId, siteName and siteUrl are set) and has subject null. Once closed, its resolution is orders_recovered, or site_deleted if the site was deleted. It carries no order count, no usual level and no percentage.

Neither can dismiss an alert. A tag check is limited to once a minute per site, and a connector check to once a minute per connector.

Switch it offCopy Anchor Link

Turn Monitor the tag off for a site on Site settings → Installation. You need the Sites: Edit permission. The same switch is available on the REST API and in the MCP server.