Set up alerts for a check

An alert rule tells octoja to notify you when a monitoring check keeps failing — through channels such as email, mobile push, a webhook, Microsoft Teams, woasi, a case in octoja, or a ticket in your PSA. A rule fires only when the check fails a set share of its recent runs, so a single blip does not wake you up. Alerts are configured on a check inside a config package.

Prerequisites

• You need the Alert Management permission (alerts.manage). Permissions are assigned under Administration → Groups.
• A config package that includes the check you want to alert on.
• If you alert through a channel, set that channel up first under Administration → Integrations — email recipients, mobile push alarm groups, webhooks, Microsoft Teams, woasi, and the PSA connections (Autotask, HaloPSA, TANSS, Jira, TOPdesk, DocBee, Codemeta OS, Odoo, Inserve, c-entron Service-Board). A ticketing or PSA system that is not connected does not appear in the channel picker at all, so connect it first. See Set up Webhooks, Send Alerts to a Microsoft Teams Channel, or Set Up the woasi Integration for the connected examples.

Alert configurations

An alert configuration is a named, reusable profile that bundles the channels an alarm goes to with the rule that decides when it fires. You build a configuration once and then pick it on as many checks as you like — change the profile and every check using it updates together. octoja ships four ready-made configurations you can use straight away:

• Immediate – Critical — the first critical result pages on-call and opens a case at once.
• Standard — a debounced default: email on sustained warnings, a case once it turns critical.
• Sustained Issue — only fires when a problem persists, for noisy CPU or memory metrics.
• Critical – Multi-stage — a confirmed critical pages on-call, pings the team channel, and opens a case.

Add an alert to a check

1. Open the config package and go to its Checks tab.
2. Open the check you want to alert on and switch to its Alert tab.
3. Pick an alert configuration for the check. You can choose an existing configuration (one of the four above or one you built), or select New alert config to create one inline.

What goes in a configuration

Inside an alert configuration you add one or more channels — where each alarm goes — and set the rule that decides when it fires. octoja can notify through any of these channels:

Each channel must be connected under Administration → Integrations before you can pick it here. A system that is not connected is not offered in the picker at all.

Set the rule once per channel. octoja alerts when at least a chosen percentage of the check's most recent results are at or above a minimum severity. A common starting point is 50% of the last 10 results at minimum severity Warning — raise the percentage or the window to make the rule less sensitive. You can evaluate the last N results (Count mode) or the last N hours (Time mode).

When you are done, save the check. The alert configuration now applies to every device the config package targets, and any other check that uses the same configuration stays in step with it.

Quiet hours for a channel

Each channel can be limited to a weekly schedule instead of alerting around the clock. Switch the channel from Always active (24/7) to Limit to schedule, then pick the weekdays and a From/To time window (evaluated in the instance time zone). Outside those times, results are not counted toward that channel's alarm.

Turn on Catch up missed alerts if you still want to hear about something that went wrong overnight: an alarm that would have fired outside the window is held and delivered once the schedule is active again, provided the check is still failing.

Email recipients

Set up email recipients under Administration → Integrations before you alert by email. A few things commonly trip people up:

• A new recipient is created disabled and receives nothing until you enable it. Use Send test first to confirm the address works — the test is sent even while the recipient is disabled — then enable it.
• Each recipient has its own language. Alert emails are sent in that recipient's language (for example German or English), regardless of who or what triggered the alert.
• If delivery keeps failing, octoja disables the recipient automatically so a bad address does not keep bouncing. Fix the address and enable it again.

Mobile push

The Mobile push channel notifies an alarm group — a list of users. Each user needs the octoja mobile app installed and signed in, and only users who have access to the affected device receive the push. Recoveries are pushed too.

When are you notified?

octoja re-evaluates a check's alert rule every time a new result for that check arrives — but a channel does not send a message on every failing run. Each channel keeps one open alarm per check and device: the notification goes out once, when the channel's rule first crosses its threshold, and the next message on that channel is the recovery once the condition clears. (See Checks for how a result gets its OK, Warning, or Critical status.)

There is no separate debounce setting on top of this — the rule itself is the debounce. How many bad runs it takes until the first notification, and how many good runs until the recovery, follows directly from the percentage, the window, and the minimum severity you set per channel.

When a check recovers

You do not have to clear alerts by hand. When a check returns to OK, octoja sends a recovery automatically:

• Webhook, Teams, Email, and Mobile push receive a follow-up "recovered" notification.
• A case that octoja opened for the alert is closed automatically. The case stays linked to the check that raised it, so you can always trace it back.
• A PSA ticket is also closed automatically — but only while no one has been assigned to it. Once a technician picks the ticket up, octoja leaves it open so their work is not lost.

Override or mute alarms on one device

A single device can depart from the package's alarm configuration without affecting the others. On the device's Monitoring Checks panel:

• Follow package — the default; the device uses the package's alarm configuration.
• Give the device its own alarm configuration to alert differently for that device only.
• Alarms off — the check keeps running and recording results, but no alarms fire for this device.

You can also Disable on this device to pause the check entirely on one device, or Override for this device to change its settings there only — then Revert to package config to return to the shared configuration.

Tips

• The flapping guard means a check that recovers on its own does not raise an alarm. Lower the percentage if you want to be told sooner.
• The alert editor flags a channel as Inactive when its integration is disabled, so alarms are not dropped silently. Re-enable the integration to resume delivery.
• Warning and Critical results always appear on the device's Checks tab as well, whether or not a rule fires.

See also: config packages, and the Webhooks, Microsoft Teams, and woasi channel guides.