Act

Ticketing

A ticketing destination turns incidents into tickets in your ticketing platform. MonitOps opens one ticket for each qualifying incident, keeps it current as the incident changes and closes it with the outcome when the incident resolves.

How it works#

Delivery is one-way: MonitOps writes to the ticketing platform and does not change the incident from what the platform reports. Inbound sync of status and assignment is planned and is described at the end of this section.

Policy#

Each ticketing destination has its own policy, which decides which incidents qualify.

Policy element	What it decides
Minimum severity	The lowest incident severity that opens a ticket, such as major
Cause classes	Which cause classes of the leading cause qualify
Customer impact	Whether the incident must affect a customer-facing journey

Two destinations can have different policies, so one platform can receive every major incident while another receives only provider-caused ones.

Lifecycle#

Incident event	Ticket action
An incident qualifies	A ticket is created
Severity changes	The ticket is updated
The leading cause changes	The ticket is updated
The incident resolves	The ticket is closed, with the outcome

Ticket events are recorded on the incident timeline.

Mapping to the platform#

MonitOps talks to the ticketing platform through a generic HTTP adapter. No platform-specific connector is required; the adapter is configured with what your platform expects.

Setting	Purpose
Endpoint	Where requests are sent
Authentication	Taken from a secret reference
Request templates	One each for create, update and close, with fields mapped from the incident
Response path	Where in the platform's reply the external reference is found
Status mapping	How the platform's statuses translate to and from the incident's

The external reference is stored with the ticket, so later updates and the close address the same ticket.

Reconciliation#

Every external effect carries a stable operation identity. If a call ends with an uncertain result, for example a timeout after the request was sent, MonitOps reads the ticket back from the platform and reconciles before it retries. A retry therefore does not create a second ticket for the same incident.

Planned: inbound sync#

Two-way sync is planned. Status and assignment changes made in the ticketing platform would be read back, either by polling a ticket or through a webhook receiver, with explicit rules for resolving conflicts. It depends on the ticketing platform your teams use and is not part of delivery today.

Configuration#

Administrators create and edit destinations. For a ticketing destination:

Open Destinations and add a destination of kind Ticketing.
Enter the endpoint and select the secret reference used for authentication.
Write the create, update and close templates and map incident fields into them.
Set the response path for the external reference and the status mapping.
Set the policy: minimum severity, cause classes and the customer-impact flag.

The destination's delivery is governed by its own persistent queue (see Destinations).

What you see in the console#

The destinations page shows the policy, backlog, errors and freshness of each ticketing destination. An incident shows the state of its ticket and the external reference.

For INC-20931, with a policy of severity at or above major, one ticket is opened when the incident opens. If severity rises, the ticket is updated, and when the incident resolves the ticket is closed with the outcome.

Limits and defaults#

One ticket per qualifying incident.
The policy is set per destination.
Only an administrator can create or change a destination.

Failure states#

State	What happens
Platform slow or unavailable	The backlog grows on that destination only; other destinations and ingestion continue
Uncertain result	The ticket is read back and reconciled before any retry
Delivery error	The error count and last error are shown on the destination
Queue saturated	A saturation state is shown rather than hidden

Last updated October 2026