Client and work management
System alerts: which ones deserve a ticket
Three questions to tell the notice that needs work from the one that only informs and the noise to switch off at the source.
An alert from your systems deserves a ticket when someone has to do something and a client is affected. The rest is information that only needs reading, or noise you should fix in the tool that sends it. To separate useful alerts from noise, gather every notice in one list, sort it by severity and decide which ones become tickets.
Think of a company that maintains the websites of thirty clients. The monitoring dashboard, the uptime checker, the nightly backups and the release process all send their notices to a shared mailbox. On Monday there are two hundred messages. The "resolved" ones mix with the "down" ones, and the backup that failed on Saturday goes unseen because it looked like the forty backups that went fine.
Three questions for every notice
Before setting anything up, agree with your team on what to do with each kind of notice. Three questions are enough:
- Does someone have to act? If not, the notice is informational.
- Does it affect a specific client? If it does, the work has to be filed under that client, with someone in charge.
- Does it repeat with nobody doing anything? Then it is noise, and it gets fixed at the source.
With those answers every notice lands in one of three places: it becomes a ticket, it is read and marked as read, or it is tuned in the sending tool so it stops arriving.
Which notices usually deserve a ticket and which do not
The ones that usually deserve a ticket mean pending work for a client: a failed backup, a site that stopped responding and did not come back, a release that stopped halfway, a server in critical state.
Informational ones say something was resolved or came back up, a backup finished fine or a container update went through. They are worth receiving, because they confirm the system is still sending, but they ask for no work.
Noise is the warning that fires again and again with nobody acting on it, such as a threshold set too low on a metric. Deleting it every morning solves nothing. You raise the threshold or change the rule in the monitoring tool, because that tool detects the problem and decides when to send a notice.
How notices arrive and get sorted in AgentticCRM
Alerts gathers in one list the notices from your monitoring tools, your backups and your own systems. It does not monitor anything on its own: it receives what your tools send. For each system you create a channel with its own private address, shown only once, and give it a default severity.
Every notice is read the same way even though each tool names its data differently. Alerts recognizes the title, the message, the severity, the incident identifier and the link. Severity comes from the words in the notice: critical, down or firing make it critical; warning, error, fail or degraded make it a warning; info, ok, up or resolved make it info. If none appear, the channel default applies.
Three details cut noise without any work from you. If the same incident arrives twice through the same channel with the same identifier, only one alert is kept. Each channel accepts at most 120 notices per minute, so a system failing in a loop cannot flood the list. And alerts do not bury your team in notifications: they are reviewed in their own list, with a count of the ones still unread.
Silence is a signal too. Each channel shows how many alerts it has received and when the last one arrived, so a system that stopped sending shows up in that date.
From alert to ticket to tasks
When an alert needs work, you click Create ticket and choose the affected client. The ticket takes the alert's title as its subject, and the message and incident link in its description. The alert is marked as read, shows Has a ticket and takes you to it in one click. Each alert produces only one ticket.
From there the work continues in support tickets: your team talks with the client and splits the follow-up into tasks with an owner, a priority and a date. The alert keeps the original technical notice, and unread critical and warning alerts appear in the daily summary on the main dashboard.
If the same alert comes back every month, write the procedure to fix it once and upload it to your internal knowledge base: a ticket's analysis draws on your documented procedures.
Who decides what counts as noise
Managing channels and reviewing alerts are separate permissions. The people handling support work the list without changing where notices come in, and whoever manages channels can pause one or replace its key if the address leaks.
Alerts that are not useful can be deleted one at a time or several at once. They leave the list, but the original notice is kept for audit and recovery. Creating a channel, replacing its key, deleting alerts or turning them into tickets is all recorded. You can also ask the Assistant to show you pending alerts or turn one into a ticket; before saving the change, it shows it to you for approval.
This flow is everyday work for MSP and IT support companies, and it serves any team that maintains systems for its clients.
Frequently asked questions
Does Alerts monitor my systems on its own?
No. Your monitoring tools detect the problem and send the notice; Alerts receives it, organizes it and puts it in front of your team.
Which tools can I connect?
Any tool that can send a notice to a web address: dashboards such as Grafana, uptime checkers, tools such as Beszel or Watchtower, backups, release processes and your own programs.
What if a channel address leaks?
Replace the channel's key from Edit channel. The old address stops working immediately and you get a new one to paste into your tool.