External tickets not created for Alerts v2: troubleshooting and recovery

Alerts v2 can send notifications through configured channels, including PSA, ITSM, email, Slack, webhooks, and other integrations. When an alert appears in Auvik but no external ticket is created, the issue is usually one of four things:

The alert is disabled, mis-scoped, or not associated with the ticketing channel.
The notification channel is missing, unhealthy, or associated with the wrong sites.
The PSA/ITSM mapping cannot create a ticket because the queue, board, project, company, status, or priority is invalid.
The alert condition has not produced a notification because of its trigger, clear, delay, suppression, or maintenance settings.

This is best treated as a standalone troubleshooting article. Auvik already documents notification-channel setup, PSA mappings, and test alerts separately; the procedure below connects those workflows into one recovery path.

Important distinction: an Auvik alert is not automatically a ticket

Every triggered Alerts v2 condition appears in Auvik’s Alerts view, even when no notification channel is assigned. An external ticket is created only when the alert is enabled, the condition triggers, and a compatible notification channel is associated with the alert and site.

For Alerts v2, notification channels are selected in the alert definition. A channel can also be associated with only a subset of the sites covered by that definition. Confirm both the alert association and the channel’s site association.

Symptoms

The alert appears in Auvik, but no PSA/ITSM ticket is created.
Email or another notification works, but the ticketing integration does not.
Tickets are created for some sites but not others.
Tickets stop appearing after an alert was migrated, edited, cloned, or moved between sites.
The integration is connected, but a ticket is not created for a particular queue, board, project, company, or priority.

Quick recovery: resave the alert definition

In some environments, resaving an affected Alerts v2 definition causes the current alert configuration and notification-channel association to be persisted again. Treat this as a recovery step, not as a substitute for checking the integration mapping.

Go to the site where the alert definition was created or is managed.
Navigate to Manage Alerts > Alerts v2.
Locate the affected definition and confirm its name, status, severity, and Entities Applied To.
Open the alert and select Edit.
If allowed, click Save without changing the configuration. Otherwise, make a benign change—for example, disable the alert, save it, enable it again, and save it.
Confirm that the alert is Enabled.
Confirm that the expected devices, interfaces, services, or other entities are in scope.
Confirm that the intended PSA/ITSM notification channel is selected and associated with the expected sites.

Editing an alert definition can reset active alert state and in-progress alert-delay timers. Avoid unrelated changes during this recovery step, and allow the alert to trigger again before concluding that the problem remains.

Step 1: Confirm that the alert is triggering

Before troubleshooting ticket creation, confirm that Auvik is producing the alert event:

The definition is enabled.
The alert is applied to the expected site or sites.
The triggering entity is included in the definition.
The trigger condition is currently true.
Any alert delay has elapsed.
A maintenance window, alert suppression, or other suppression rule is not preventing notification.
The alert has not cleared before the delay completed.

Alerts v2 can use time-based delays. If the condition returns to normal before the delay expires, Auvik does not create the alert or send the notification, and the timer resets.

If the condition is present in Auvik’s alert view but no notification is sent, inspect the definition and channel. If no alert appears at all, troubleshoot the trigger, entity scope, data collection, delay, or suppression first.

Step 2: Confirm the alert source and scope

Auvik supports both legacy and Alerts v2 definitions. The Source field in alert details identifies whether an event came from a Legacy or V2 definition.

Confirm that:

You edited the Alerts v2 definition rather than a similarly named legacy alert.
The definition was created at the intended site or account level.
The alert has not been cloned into a separate definition that lacks the ticketing channel.
The entity scope includes the device or interface that generated the test condition.
The alert is not disabled at the test site.

Alerts v2 definitions can be created at different levels of the account hierarchy and applied to selected sites. The creation site controls where the definition can be edited, so an alert may be visible at a site without being editable there.

Step 3: Verify the notification channel

Go to Manage Alerts > Notification Channels and verify the channel used by the alert.

Check that:

The channel exists and is the intended PSA/ITSM integration.
The channel is associated with the alert definition.
The channel is associated with the site where the alert triggered.
The channel has not been deleted, disabled, or replaced.
The channel points to the intended queue, board, project, or ticket destination.
The channel is not limited to a different subset of sites.

An Alerts v2 definition can have zero, one, or multiple notification channels. An alert with no channel still appears in Auvik but cannot create the external ticket.

Step 4: Check the PSA or ITSM mapping

ConnectWise PSA

In Integrations > ConnectWise PSA > Manage Alerts, verify that:

The intended service board is configured and active.
The board statuses used by the integration are active.
A status mapping exists for the board.
Create new ConnectWise tickets on this Service Board is selected.
Auvik severities map to valid ConnectWise priorities.
The Auvik site maps to an active ConnectWise company and, where applicable, site.
The notification channel uses the correct service board.

Auvik documents that inactive service boards or mapped statuses prevent alerts from creating or updating ConnectWise tickets. If tickets move from a triage board to an action board, configure both boards in Auvik so the alert-to-ticket relationship and callbacks remain intact.

Autotask PSA

In Integrations > Autotask PSA > Manage Alerts, verify that:

The intended ticket queue is configured and available.
Create new Autotask tickets on this Ticket Queue is selected.
Auvik severities map to valid Autotask priorities.
The Auvik site maps to the correct Autotask company and site.
The notification channel uses the intended queue, issue type, and sub-issue type.
Any triage and destination queues are both configured if tickets are moved after creation.

Status mappings control whether closing a ticket dismisses the Auvik alert and whether an open alert can cause a ticket to reopen. These settings affect ticket lifecycle after creation, but an invalid queue or missing create-ticket mapping can prevent initial creation.

Zendesk or email-to-ticket workflows

For Zendesk or another email-to-ticket system:

Confirm that the Email or Zendesk-compatible channel is assigned to the alert.
Verify the destination support address.
Check mail-flow logs, spam filtering, allow lists, and mailbox rules.
Confirm that the destination mailbox converts incoming messages into tickets.
Verify that the alert’s site association includes the test site.

Auvik’s documented Zendesk workflow uses an Email-to-Zendesk address as the recipient of an Email notification channel, after which Zendesk converts the message into a ticket.

Webhook or custom ITSM integrations

For a webhook or custom ticketing system:

Confirm that the webhook channel is assigned to the alert.
Verify the endpoint URL, authentication, and response status.
Check the receiving system’s logs for the request and validation errors.
Confirm that the endpoint returns the expected response if Auvik should display an external ticket ID or link.
If tickets are created by polling Auvik’s Alert API, verify that the job is running and is not filtering out Alerts v2 events.

Step 5: Test the integration safely

Test the notification channel first

Auvik provides a Send Test Alert function for notification channels:

Go to Manage Alerts > Notification Channels.
Select the notification channel.
Click Send Test Alert.
Select the site from which the test should originate.
Send the test.
Confirm delivery in the PSA/ITSM system or destination mailbox.

This tests the channel path without waiting for a production condition. Available behavior depends on the channel type.

Interpret the result as follows:

Test fails: troubleshoot integration health, authentication, queue/board/project mapping, or the destination system.
Test succeeds but a real alert creates no ticket: troubleshoot alert association, entity scope, delay, suppression, and the alert’s channel selection.
Auvik alert exists but no channel test applies: verify the alert is associated with the channel and the channel applies to the triggering site.

Test the alert definition end to end

If the channel test succeeds:

Use a non-production device or maintenance-approved test site where possible.
Temporarily lower a threshold or adjust the condition so it triggers.
Confirm the condition is true on an in-scope entity.
Allow the configured alert delay to expire.
Confirm the alert appears in Auvik and a ticket is created.
Restore the original threshold or condition immediately afterward.
Confirm that the alert clears according to its clear condition.

Record the test time, site, alert name, entity, channel, and resulting ticket ID.

If tickets still are not created

Re-authenticate the integration

If the channel test fails or integration health is degraded, re-authenticate or reconnect the PSA/ITSM integration according to its Auvik setup guide. Confirm that the integration account can create tickets, read queues or boards, map companies, and update ticket status where required.

Review integration and communication logs

Check Auvik integration status, notification history, PSA/ITSM API or audit logs, email gateway logs, mailbox logs, and webhook request/response logs. Look for authentication failures, inactive boards or queues, invalid company mappings, missing required fields, rejected priorities, rate limits, duplicate suppression, or malformed webhook responses.

Check for duplicate or competing definitions

If a legacy and Alerts v2 definition monitor the same condition, they may use the same channel and generate duplicate notifications or tickets. Compare alert name, source, entity scope, trigger condition, and channels before enabling a replacement definition.

Check whether the alert cleared before notification

If the alert uses a clear condition or delay, it may resolve before the notification is sent. Review the trigger, delay, clear condition, suppression settings, and event timestamps.

Information to provide Auvik Support

Collect the following:

Account and site name
Alert definition name and source: Legacy or V2
Definition creation site or permission level
Alert status and entity scope
Trigger, clear condition, and alert delay
Notification channel name and type
PSA/ITSM platform, queue, board, project, and company/account
Test time window, including timezone
Device, interface, service, or other test entity
Auvik alert ID and external ticket ID, if partially created
Screenshots or exported alert/channel configuration
Integration, PSA, email, or webhook error messages

Do not include API keys, passwords, or other credentials in a support request.

Prevention checklist

Name definitions with their source and purpose, such as V2 - High CPU - Core Devices.
Confirm the definition is enabled and correctly scoped.
Associate the correct notification channel and verify its site association.
Confirm the PSA queue, board, project, priority, status, and company mapping.
Use an alert delay appropriate for the condition.
Test the notification channel before relying on the alert.
Test a real alert condition in a controlled environment.
Record the resulting ticket ID and expected clear behavior.

Summary

When an Alerts v2 alert appears in Auvik but no external ticket is created, first confirm that the alert triggered and that the notification channel is associated with both the alert and site. Then validate the PSA/ITSM queue, board, project, company mapping, priority, status, and create-ticket setting.

Resaving the affected alert definition is a useful recovery step when configuration changes have not been persisted correctly, but it should be followed by a channel test and a controlled end-to-end alert test. If the problem remains, collect alert, channel, site, mapping, timestamp, and integration-log details before contacting support.

How can we help?