How uptime alerts become PSA tickets
Published . Updated .
This guide explains how a down alert becomes a single ticket in the PSA your techs already watch, and how the recovery email can close that ticket instead of opening a second one.
The fastest way is email-to-ticket: point alerts at the mailbox your PSA already turns into tickets, then use parsing rules to set the company, board, and priority. Down and recovery emails with a stable subject let rules open one ticket and close it on recovery.
A PSA is the system where the work lives. A monitor that only sends mail to a person's inbox dies when that person is on leave. A monitor that opens a ticket lands in the queue, with a company, a priority, and a clock. You do not need a private API for that if the PSA already creates tickets from mail. Most of them do. Each PSA names this feature differently, and menu paths move between versions, but the behavior to ask for is the same.
How does each PSA take mail?
ConnectWise PSA, formerly ConnectWise Manage, handles this with its Email Connector. An administrator sets it up under System > Setup Tables > Email Connector List, points it at a mailbox, and picks the default service board and company. Parsing rules at the bottom of each connector read the subject line and can set the company, priority, and status. Menu paths can shift between versions, so check ConnectWise's online help before you train a new tech on a path from memory.
Autotask calls this Incoming Email Processing. It lives under Admin > Extensions and Integrations > Automation > Email Notifications and Surveys. You create a mailbox there, and Autotask gives you an address that turns mail into tickets. Then you set the default queue, status, and account matching, and send your alert mail to that address.
HaloPSA connects a mailbox under Configuration > Email > Mailbox Setup, and new mail to that mailbox becomes a ticket of the type you choose. Email Rules, under Configuration > Email > Email Rules, match on the sender, subject, or body and can set the ticket type, client, and other fields. Syncro turns mail into tickets through a mailbox under Admin > Emails/SMS > Mailboxes. By default it creates a ticket only when the sender matches an existing customer, and a monitoring service's address won't match one, so add an Email Rule under Admin > Emails/SMS > Email Rules that matches the alert's sender or subject and assigns the right customer. In all four, the reliable design is the same: one address per monitoring stream, a subject the rule can match, and a company name in the subject or body that the rule already knows.
Do not share one mailbox with newsletters and with alerts. The rule will eventually file a down notice as a sales lead, or file a newsletter as an outage.
| PSA | Where it's set up | What the rule must do |
|---|---|---|
| ConnectWise | Email Connector, with parsing rules | Open a ticket on the service board for the right company |
| Autotask | Incoming Email Processing | Set queue, company, and priority from the message |
| HaloPSA | Mailbox Setup and Email Rules | Set ticket type and priority, and match the company |
| Syncro | Mailboxes and Email Rules | Open one ticket and keep replies on it |
What should the subject look like?
The subject is the API. Keep it stable.
A down message and a recovery message should share a token the rule can find, and they should differ by one word the rule can branch on. Down: Northwind booking and Up: Northwind booking are enough if the company match is "Northwind" and the state match is the first word. Put the state first so a thread view still shows it. Put the client and the check name where a parser can slice on a colon or a bracket.
Do not put the timestamp in the subject. A new timestamp is a new ticket. Do not put the incident id only in the body if the rule you have can only read the subject. If you need an id so the recovery finds the original ticket, put the same id in both subjects and teach the rule to match it.
Replies from a tech should stay on the ticket. Set the reply-to address to a mailbox that threads, or leave reply-to alone and tell techs not to answer the alert as if the monitor were the client. The client is not that mailbox.
How do you close on recovery?
The recovery message is a second email, not a duplicate outage. The rule should find the open ticket for that check and close it, or move it to a "recovered, confirm" status if you want a person to glance at it. Automatic close is right when the check is the whole incident. A human confirm is right when the site can answer HTTP and still be wrong, such as a booking form that returns a 200 and an empty page. You will learn which checks are which.
If the rule cannot match, it will open a second ticket titled Up. That ticket is noise, and it hides the fact that the first ticket is still open. Test the pair. Send a down, confirm one ticket, send an up, confirm the same ticket moved. Do this with a test company before you point forty clients at the address.
Storms happen when every minute sends a new message. Confirmation and state-change alerts are what keep the mailbox to two messages per incident. Read confirming outages before you widen the rule. A flapping check will open and close tickets all night if you let every sample through.
What are the alternatives to email?
A webhook posts a JSON body to an address you run. You can verify a signature, then create the ticket with the PSA's own API. That is more work and it survives subject-line edits. It is the right next step when email parsing breaks twice in a month.
PagerDuty, and a Teams workflow that posts into a channel, are routes for a human who is not watching the board. They are not a substitute for the ticket if your contract says every client incident has a ticket number. Use them beside the ticket for the few checks that justify a page. The comparison of tools that offer these routes is in Pingdom alternatives.
A REST connector inside the monitor, the kind that logs into ConnectWise as an API user, is a different product decision. It can set every field. It also breaks when the PSA changes the API, and it stores credentials you must rotate. Email uses a mailbox you already administer. Start there.
- One mailbox per alert stream, not the sales inbox.
- Subject starts with Down or Up, then a stable check name.
- The rule sets company, board, and priority.
- Recovery finds the open ticket and closes it or parks it for a glance.
- Test one down and one up before you add the rest of the clients.
How The Watchbill helps
On Pro and Business, The Watchbill sends a ticket email when a confirmed outage opens and again when it closes. The subject starts with "[Watchbill] Down:" or "[Watchbill] Up:" followed by the site name. That's the stable, state-first subject this guide recommends, so one parsing rule can open the ticket and another can find it and close it. Because a site is marked down or up only after two consecutive minutes agree, you get one pair of messages per incident instead of a message every minute.
The same plans can send a signed webhook, a Microsoft Teams Workflows message, and a PagerDuty alert. The webhook body is signed with HMAC-SHA256, so your receiver can confirm it came from The Watchbill. There's no REST connector into ConnectWise, Autotask, HaloPSA, or Syncro; ticket email is the route. Plan details are on the pricing page, and the terms webhook, HMAC, and email-to-ticket are defined in the glossary.
Sources
- ConnectWise PSA online help (Email Connector). Accessed October 10, 2026.
- Autotask help, Service Desk automation (Incoming Email Processing). Accessed October 10, 2026.
- HaloPSA guide, Mailbox Setup. Accessed October 10, 2026.
- HaloPSA guide, Email Rules. Accessed October 10, 2026.
- Syncro, Automatically create tickets from inbound emails. Accessed October 10, 2026.
- Syncro, Automate tasks with email rules. Accessed October 10, 2026.