The alert fired. The ticket never appeared. Trace the handoff.
An alert record proves that a monitor changed state; it does not prove that the service desk received owned work. Use these 24 checks to trace monitor evaluation, suppression, route selection, integration delivery, ticket creation, deduplication, queue ownership, recovery, and closure before replaying the event.
1. Preserve the missing handoff
- Record the customer tenant, site, endpoint or service, monitor, alert ID, severity, state, first-seen time, last change, time zone, and expected ticket destination.
- Capture the alert history, route or policy version, suppression state, maintenance window, integration identity, delivery attempt, response, retry, and audit events before changing anything.
- Search the downstream system by alert ID, device identity, customer, summary, correlation key, source, and time window; check unexpected, closed, merged, spam, and unassigned queues.
- Define the expected ticket fields, queue, owner, SLA, deduplication behavior, recovery action, stop condition, and escalation owner.
2. Prove alert eligibility
- Confirm the monitor actually crossed its configured threshold and produced the intended active alert rather than a warning, transient sample, stale record, or display-only state.
- Verify that customer, site, device class, operating system, tag, policy, severity, and schedule match the ticket-routing rule in effect at the event time.
- Check acknowledgement, suppression, maintenance, dependency, flapping, quiet-hours, deduplication, recurrence, and auto-resolution rules separately.
- Compare one affected alert with a successful alert from the same route and an unaffected alert from the same time window to isolate the first differing condition.
3. Trace route and mapping
- Identify the exact route selected, its enabled state, priority, conditions, destination, integration version, and configuration change history.
- Validate customer, company, contact, site, queue, board, project, category, priority, status, assignee, and SLA mappings without inventing fallback ownership.
- Check whether a missing or retired downstream object, renamed queue, invalid custom field, unsupported value, or required-field change rejected the ticket.
- Confirm that credentials, tokens, certificates, scopes, tenant selection, source IP rules, and secret rotation remain valid for the intended destination.
4. Inspect delivery evidence
- Locate the outbound request, webhook, connector job, message, or queue item and retain its correlation ID, payload hash, attempt time, destination, and redacted response.
- Distinguish no delivery attempt, client rejection, authentication failure, permission denial, validation failure, rate limit, timeout, server error, and accepted-but-not-created outcomes.
- Review retry count, backoff, queue age, dead-letter state, ordering, concurrency, duplicate key, idempotency key, and replay limits.
- Correlate provider status and downstream audit logs with the same time window; do not treat a generic HTTP success as proof that a usable ticket exists.
5. Recover without duplication
- Before replaying, prove whether the original request created, merged, updated, suppressed, or partially created any downstream record.
- Correct the narrow verified mapping, identity, route, queue, or schema defect and retain the actor, change, approval, time, previous value, new value, and rollback.
- Run one synthetic or approved canary alert with a unique correlation value, bounded destination, monitored delivery, explicit timeout, and duplicate check.
- Do not disable deduplication globally, broaden route scope, lower authentication, expose secrets, or create an unbounded retry merely to force ticket creation.
6. Validate ownership and closure
- Verify the canary produced one ticket with the correct customer, device, queue, severity, summary, evidence, timestamps, owner, SLA, and bidirectional reference.
- Test acknowledgement, assignment, escalation, alert recovery, ticket update or closure, reopen behavior, and maintenance handling as separate states.
- Reconcile the affected time window into ticket created, merged, suppressed by design, failed, retried, dead-lettered, unknown, or owned-exception outcomes.
- Record root cause, prevention change, monitoring of the integration itself, residual risk, customer impact, owner, review date, and closure evidence.
Definition of a working alert-to-ticket route
The route works only when a controlled alert produces exactly the expected owned service record for the correct customer and endpoint; the delivery and downstream records share a traceable identity; required fields, severity, queue, SLA, and evidence are correct; duplicates and retries are safe; recovery behavior is verified; and every failure, suppression, dead-letter item, or unknown outcome has an owner and dated next action.
Alert delivery and routing references
Connector and webhook responses are evidence, not the whole outcome. The IETF standards define HTTP semantics and a machine-readable format for API errors. Fraser McLean's practical notification guide separately demonstrates why an explicit destination, authentication boundary, reachable route, and controlled end-to-end test matter; ntfy and Apprise notification delivery is an example, not proof of PSA ticket creation.
- RFC 9110: HTTP Semantics
- RFC 9457: Problem Details for HTTP APIs
- Fraser McLean: Self-hosted notifications with ntfy and Apprise — configure a named destination, secure access, verify network reachability, and send a controlled test notification.
RMM alert-to-ticket troubleshooting questions
Why did an RMM alert fire without creating a ticket?
The alert and ticket are separate records connected by a route. Check routing conditions, suppression and maintenance behavior, customer and queue mappings, integration identity, API responses, rate limits, deduplication, downstream availability, and unexpected queues or correlation keys.
Should I resend an alert when the ticket is missing?
Only after preserving the original evidence, searching for an existing or partial ticket, and confirming that replay is idempotent or safely deduplicated. Blind retries can create duplicates or conflicting ownership.
What proves alert-to-ticket routing works?
A controlled test should show the monitor event, alert ID, selected route, mapping, delivery attempt, downstream response, ticket ID, correct customer and queue, severity, timestamps, ownership, recovery behavior, and reconciliation of duplicates and failures.