Ticket lifecycle
A Tidehawk ticket exists because an alert fired, and it goes away because the underlying certificate or domain was renewed.
When a ticket is created
Section titled “When a ticket is created”A ticket is raised when an alert fires on a rule with the PSA ticket channel switched on. The ticket job is queued in the same transaction that records the alert, so a ticket is never lost between the two.
Tidehawk also raises a ticket without any rule in one case: a certificate on the manual renewal track within 45 days of expiry gets a proactive ticket, so nobody has to remember a certificate they have to renew by hand.
Which PSA receives it:
- If the rule names a provider, that provider’s connection is used, and it must be active.
- If the rule names none and exactly one PSA is connected, that one is used.
- If several are connected and the rule names none, no ticket is raised and the reason is recorded against the alert.
The “PSA ticket pending” state
Section titled “The “PSA ticket pending” state”Before Tidehawk calls your PSA, it claims the ticket slot on the alert, and writes the reference to the real ticket afterwards. That claim is what stops a retry raising a second ticket. It also leaves a brief window where the slot is taken and no reference exists yet. Tidehawk will not tell you a ticket was raised when it cannot name one, so during that window the Alerts page shows Ticket pending.
| What you see | What it means |
|---|---|
| Queued | The ticket job has not run yet. Normal for the first few minutes. |
| Ticket pending | The slot was claimed more than an hour ago and no ticket reference was stored. Worth investigating. |
| Ticket raised | A real ticket exists. Where the PSA returned a link, the chip opens it. |
| Failed | The attempt did not succeed. The reason is recorded against the alert. |
| Not in this rule | The rule that fired has no PSA channel. |
A retry never raises a second ticket
Section titled “A retry never raises a second ticket”If the call to your PSA fails, Tidehawk hands the slot back and lets the job retry, up to three attempts with a growing delay. Because the alert itself can only exist once per item and threshold, a retry can only ever produce the one ticket. Jobs that exhaust their retries land in a dead-letter queue for the Tidehawk team to inspect.
If the ticket was created but the reference could not be stored, Tidehawk does not retry. Retrying would raise a duplicate in your PSA. The alert stays in the pending state and the failure is reported to Tidehawk’s own monitoring.
When and how a ticket is closed
Section titled “When and how a ticket is closed”Closing is driven by Tidehawk’s own evidence, never by the status of the ticket in your PSA.
- A newer certificate for the same name is discovered, or a registry lookup shows the domain expiry has moved beyond the alert’s threshold.
- Tidehawk resolves the alert and queues a close for every alert that opened a ticket.
- The close job posts an internal note on the ticket saying that Tidehawk resolved it, naming the renewed certificate and its new expiry date where it knows them.
- If the connection has a closed status configured, the ticket is moved to that status.
The outcome recorded against the alert is one of three things:
- Closed. Note posted and the ticket moved to your closed status.
- Noted. Note posted, no closed status configured, so the ticket is left open for a human.
- Unsupported. The provider has no verified close path, so nothing is sent and the ticket is left for you. This applies to Autotask, NinjaOne and Syncro.
A ticket that no longer exists in the PSA counts as noted, not as a failure.
What happens if your PSA is down
Section titled “What happens if your PSA is down”Each call to your PSA is given 30 seconds to answer, so an unresponsive endpoint fails quickly rather than holding the queue. The create and close jobs both retry on a network or API failure, three attempts with a growing delay. The error text is stored against the alert so you can see what your PSA said.
Nothing is lost while the outage lasts. The alert stands whether or not a ticket was raised, and the email channel is unaffected because the two are delivered independently.
If credentials stop working entirely, the Integrations card turns to Connection error or Needs attention and no further tickets are raised until you reconnect.