Monitoring
Alerts
Learn which alerts SQL Flow raises and what each means, and how to acknowledge and resolve them.
The Alerts page lists incidents and warnings that SQL Flow raised for your pipelines. Each alert names one pipeline, and you work through it from Open to Acknowledged to Resolved.
The Alerts item in the top navigation shows a red count of open alerts, and the bell icon shows a red dot. The three newest open alerts are also on the Overview. To send alerts to Slack, Microsoft Teams, PagerDuty or any HTTP endpoint, see Notifications.
Severity
| Severity | Chip | Meaning |
|---|---|---|
| Critical | Red | The pipeline needs an operator now. SQL Flow has stopped trying to recover it. |
| Error | Red | Something failed. |
| Warning | Amber | Something may fail soon, or needs a decision. |
| Info | Indigo | Not used by built-in alerts. You can choose it as a notification channel's minimum severity. |
Alerts SQL Flow raises
| Title | Severity | Raised when | What to do |
|---|---|---|---|
| Pipeline failed | Error | A pipeline fails. The message is the failure reason. | Open the pipeline and read its health reasons. Check Logs for the history. |
| Pipeline failed: needs operator | Critical | Automatic restart stopped, because the fault can't be fixed by a restart or because the restarts ran out. The message names the fault. | Fix the cause named in the message, then start or reload the pipeline. |
| Agent command '<command>' failed | Error | A command you issued, such as Start, Pause or Reload, failed on the agent. The message is the agent's error. | Fix the cause and issue the command again. |
source_truncation_point_held_by_another_session | Error | Another session on the source SQL Server is acting as the log reader for the pipeline's database, so SQL Flow can't release the source log, and the log grows. | End the other session, as the message says. |
source_log_hold_budget_exceeded | Error | The source log hold reached its budget. If the pipeline wasn't capturing, the hold was released so the source can truncate its log, and the pipeline stops when you resume it. | Reload the pipeline, as the message says. |
source_log_hours_to_loss | Warning | A pipeline that holds the source log may reach its budget within 24 hours, then within 6 hours, then within 1 hour. | If the pipeline is capturing, restore spool capacity or apply progress. If it isn't (it failed, its agent stopped, or it is starting), fix the cause and resume it, pause it to release the hold at once, or delete it. |
source_log_resume_may_need_reload | Warning | A pause released the source log hold, and the source keeps no log backup SQL Flow can read. Once the source truncates its log, the pipeline needs a reload. | Resume before the source truncates its log, or plan for a reload. |
| Data drift: target differs from source | Error | A compare found rows that still differ after its re-check. | Open the pipeline's Compare tab, then repair the drift. |
| Compare failed | Warning | A compare run failed. The message is the reason. | Fix the reason and run the compare again. |
| Scheduled key repair skipped | Warning | The automatic repair policy wanted to repair after a compare, and the repair was refused. The message is the refusal. | Resolve the refusal, then repair the keys yourself. |
| Scheduled key repair not completed | Warning | A scheduled key repair was abandoned. The message says why. | The next scheduled compare decides again. To check sooner, run a compare. |
Agent command '<command>' failed is listed here but isn't sent to notification channels.
The source_… alerts are shown by their codes and apply only to SQL Server DirectLog pipelines, whose capture holds the source's transaction log. The budget is 85 percent of the log's capacity: the size of its files plus the growth they may still take, limited by free disk space. The 24, 6 and 1 hour warnings each appear when the estimate first reaches that tier, and again if it moves to another tier. Nothing is raised when it recovers. See Hold alerts and Source log retention.
Acknowledge and resolve alerts
The page has three tabs, Open, Acknowledged and Resolved, each with a count of every alert in the account. The list holds only the most recent alerts, and says so when the account has more.
| State | Meaning | Buttons on the row |
|---|---|---|
| Open | New. Nobody has looked at it. | Acknowledge, Resolve |
| Acknowledged | Someone is on it. | Resolve |
| Resolved | Dealt with. | None |
- Select an alert to open its pipeline, or select Acknowledge to say you are working on it.
- When the cause is fixed, select Resolve.
Alerts don't close themselves: a pipeline that recovers leaves its alerts open. Resolve them so the count in the navigation shows what still needs attention.
To handle many at once, use Acknowledge all and Resolve all at the top right (they read Acknowledge recent and Resolve recent while the page receives live updates). They act on the recent alerts in the list, not on every alert in the account.
Filter alerts… keeps the alerts whose title, pipeline name, pipeline ID or message contains the text.
How long alerts are kept
Open and acknowledged alerts are kept until you resolve them. Resolved alerts are deleted 14 days after you resolve them.
Who can change alerts
Every member of the account can read alerts. Acknowledging and resolving need the Account admin or User role. See Accounts and team.
