Skip to content

Alerts

Reactive Kubernetes event watching plus a proactive rules engine with fourteen condition types, delivered through seven outbound integrations and able to consume Alertmanager firings inbound.

Tier: Free — some features Pro

What it does

Alerts covers both reactive event watching and a proactive rules engine, plus outbound integrations. KubeManta watches Kubernetes Warning events across tenant namespaces — CrashLoopBackOff, OOMKilled, BackOff, and similar — classifying them by severity and deduplicating for five minutes so a flapping resource doesn't flood the feed with near-identical entries.

The rules engine supports fourteen condition types: pod restart threshold, pod phase match, pod not ready, deployment degraded, node condition, PVC unbound, event pattern, job failed, metric threshold, scan severity threshold, system event, application health, log pattern, and SLO burn rate. Rules are evaluated every 30 seconds, with a per-rule cooldown so a persistently failing condition fires once and then waits rather than re-alerting every evaluation cycle.

One history

Everything that fired is in one list, under the live alerts on the Alerts tab: your rules' firings, KubeManta's built-in pod watcher (CrashLoopBackOff, OOMKilled, image pull failures, stuck Pending) and alerts received from Prometheus Alertmanager, which carry an Alertmanager tag. It is kept for 180 days, follows the namespace you are viewing, can be searched by alert or workload, and pages ten at a time. Viewers can read it. Admins can clear it and open the same firings in Activity, filtered to alerts, beside everything else that happened at the time. The firing history on the Alerts tab is part of Pro; the live alerts above it are on every tier.

The history is stored in KubeManta's database, so an agent restart does not shorten it. The API serves the same list: GET /alerts returns it as history (newest first, 500 entries by default, up to 5,000 with ?limit=), and clearing it — from the Alerts tab, DELETE /alerts/history or DELETE /alerts/firings — clears that one list everywhere it appears, including Activity and incident reports.

Alerting on an application's health

An application health rule watches one saved Application and fires when its rollup verdict goes bad and stays bad. Pick the application, choose whether it fires on degraded (which means degraded or down — nobody wants an alert that stays silent through a total outage because they picked the milder trigger) or only on down, and set how long the bad state must persist before it fires.

It deliberately fires once for the whole application, not once per member: a three-pod app with one cause should page you once. An unknown verdict never fires — that means the selector matches nothing, which is a configuration mistake rather than an outage, and paging for it trains people to ignore the alert. A cluster read failure does not fire either: the API server blipping is not your application going down.

Alerting on an SLO's error budget

An SLO Burn Rate (error budget spent too fast) rule watches one service level objective (defined on an application's page — see Applications) and fires when its error budget is being spent too fast. It uses the two-window rule from the Google SRE Workbook, with two tiers:

  • Fast burn — more than 14.4 times the sustainable rate over both the last hour and the last 5 minutes. Sent as critical.
  • Slow burn — more than 3 times over both the last 6 hours and the last 30 minutes. Sent as warning.

The severity comes from the tier, whatever severity the rule itself is set to, and you can choose Fast burn only. Needing both windows is the point: the long window shows the burn is real rather than a blip, and the short one shows it is still happening, so a brief spike alone never fires and the alert stops soon after the problem does. A window without enough data cannot vote — an SLO that has only been measuring for a few minutes will not page on those few minutes. If the SLO is not measurable at all (see Applications), the rule stays quiet rather than guessing.

The firing names the SLO and the tier, and carries both burn rates and how much budget is left. A slow burn that becomes a fast one pages immediately — it is not held back by the slow burn's cooldown. It is otherwise an ordinary rule: the same cooldown, grouping, delivery limits, integrations and firing history as every other. For an application measured from pod readiness, the alert carries the logs and events of the application's pods that were not ready.

Burn-rate rules on SLOs measured from pod readiness are Free; on SLOs measured from your Prometheus they need Pro, like the SLO itself.

Alerting on a log pattern

A log pattern rule matches text in your pods' logs and fires on N matches within a window — never per line. A crashlooping pod reprints its error on every restart, so per-line firing is a pager that never stops.

Configure it with the text to match, a pod selector, optionally a container name, and the threshold and window. Matching is substring by default and regular expressions are opt-in. That is a deliberate safety choice: the match runs inside the evaluation loop, and a catastrophically backtracking regex would be a denial of service against alerting itself — the subsystem whose failure is least visible, because a dead alerter looks exactly like a quiet cluster. Substring matching covers the common case (OutOfMemoryError, panic:) and is linear by construction.

If you do use a regex, the risk is bounded rather than eliminated, and it is worth knowing how: every line is truncated before matching, and the scan stops once it has spent its time budget for that tick — so one bad rule costs a slice of one evaluation instead of your alerting.

Log scanning has its own interval (60s by default) rather than running on every 30-second tick, and is bounded per tick in pods scanned and bytes read, so turning it on does not make the agent read your cluster continuously. Those bounds are environment-tunable (ALERT_LOG_SCAN_INTERVAL_SECS, ALERT_LOG_MAX_PODS, ALERT_LOG_MAX_BYTES_PER_POD, ALERT_LOG_MAX_BYTES_PER_TICK) if your cluster needs different limits.

Integrations

Integrations cover Slack, Telegram, Email/SMTP, PagerDuty, CloudWatch, Datadog, and a generic Webhook. Each enabled destination is attempted independently, with its own 10-second timeout, so one destination's outage never silently suppresses the others. They are attempted in sequence, so several slow destinations add up.

Telegram alerts are sent as plain text, on purpose. Telegram's Markdown modes require escaping a long list of characters, and alert text is not ours to control — it carries pod names, container names and raw Kubernetes event messages. A single unescaped _ or *, routine in a name like api_gateway-7d9f, makes Telegram reject the whole message, so the alert about the strangest-looking workload would be the one that never arrived. Setting up the destination takes two steps that are easy to do in the wrong order: a bot cannot open a conversation, so message it (or add it to your group) before asking it to message you, or the first Test returns "chat not found". Alertmanager ingest lets KubeManta act as an alert consumer as well as a source — point an Alertmanager receiver at its webhook and inbound firings land in the same feed as everything KubeManta detects itself.

The receiver's reply says what it actually did, so a misconfigured sender is distinguishable from a working one. It reports how many alerts were ingested, how many failed to store, and how many were resolved_ignored — Alertmanager sends resolved notifications by default and KubeManta has no auto-resolve, so those are counted and dropped rather than passed over in silence. A shared secret is required: with none configured the webhook refuses everything, since it writes to your alert history. A body that is not a JSON object is rejected with a 400 rather than a server error, because Alertmanager retries a 5xx forever and a malformed sender would otherwise loop against it.

Every delivery attempt is recorded. For each alert, each configured channel gets its own receipt — sent, failed, or skipped — with the destination, the HTTP status or error, and how long the attempt took. This exists because "the alert fired" and "the alert arrived" are different claims, and only the second one matters at 03:00: an integration that has been quietly rejecting every message since a token expired looks identical, from the alert feed alone, to one that is working. Receipts also make delivery auditable after the fact — you can answer "was anyone told, and when" from the record rather than from memory. URLs and tokens in destinations are redacted before storage, so a receipt can be read by anyone who can read alerts without handing them the webhook.

What an alert carries

Every alert KubeManta sends includes what the cluster reports about the failure, so the first minutes of an incident do not start with opening the dashboard. This is included on every tier and needs no AI:

  • What the cluster reports — the pod's current problem (for example CrashLoopBackOff or OOMKilled), its workload, restart count, how long it has been failing, its last exit reason and code, and the image it runs.
  • Recent changes — a rollout of the pod's Deployment in the last day, and Helm operations made through KubeManta in that namespace in the last few hours.
  • Recent events — the latest Kubernetes events for the pod.
  • Incident — the open incident this alert belongs to, and whether anyone has acknowledged it.
  • Recent logs — the last dozen log lines, from the previous container when the pod has restarted, because that is where the crash is.

Secrets, tokens and passwords are redacted from events and logs before anything leaves KubeManta, and every section is size-limited so the whole alert fits even the strictest destination. Each destination shows it in its own way: sections in Slack, the message body in email, Telegram, Datadog and CloudWatch, the incident_story field of PagerDuty's custom details, and — for the generic webhook — a structured story object plus the same text as story_text. Existing webhook fields are unchanged.

When a rule names a workload rather than a pod — a degraded Deployment, for example — the story is about that workload's most unhealthy pod.

When there is nothing to attach, the alert says so. An alert that carries no namespace and pod labels — typically an Alertmanager alert about a node, a service or the cluster itself — is delivered as received, with a line explaining that no cluster context could be attached. The same happens when the pod named in the alert no longer exists, when its namespace is outside the namespaces KubeManta is set to read, or when the cluster does not answer within a few seconds. KubeManta never borrows context from something else to fill the gap, and a slow cluster delays an alert by seconds at most, never stops it.

Send test alert on an integration sends an example of this context, clearly marked as an example, so you can see how a real alert will look in each destination.

AI diagnosis after an alert

With Admin → AI → Alert diagnosis switched on, a short AI diagnosis follows each alert at or above the severity you choose. It is written from the same information the alert carried, sent to the same integrations the rule uses, and marked as an AI diagnosis. Where the destination supports it, it joins the alert: PagerDuty adds it to the open incident, Datadog groups it with the alert event, and email clients show it as a reply. Slack and Telegram show it as the next message, naming the alert it answers. The diagnosis also appears on the incident's timeline.

  • It uses the AI provider saved under Admin → AI → Provider, including a local provider such as Ollama, and follows your AI guardrails: the AI switch, data residency, cost caps, the egress allowlist and prompt auditing.
  • It is read-only. It cannot run commands or change the cluster; any action it recommends needs a person.
  • It counts toward the same delivery caps as the alert itself, and its delivery receipts are labelled "AI diagnosis".
  • If a diagnosis cannot be produced — AI is switched off, the provider is unreachable, a cost cap is reached — the Activity feed says so. The alert itself has already been delivered.

The setting is admin-only, and every change is recorded in the audit log. It is part of Pro; on a lapsed licence it can still be switched off. Until an admin saves it, it follows your install values (agent.alertInvestigation and agent.alertMinSeverity).

Starting from a template

Four templates sit above the rule list, under Start from a template: crash-looping pods, OOMKilled, image cannot be pulled, and stuck Pending. Each can be written by hand, but a template saves you knowing where the condition lives — for example, that "my images are broken" is Pod → Phase Match → an ImagePullBackOff chip.

A template fills the form in and stops there. It never saves a rule, because the namespace and the channels are the parts only you can know.

Stuck Pending carries a delay, and the others do not. CrashLoopBackOff and ImagePullBackOff are backoff states — the kubelet has already retried and given up, so seeing one is the alert — and OOMKilled is terminal. Pending is different: every healthy pod is Pending for a moment while it schedules and pulls an image, so a rule on Pending with no floor fires on every normal rollout. The template therefore asks for ten minutes, and the field ("Only if it has been that way for") appears whenever you select Pending on any rule. Leave it empty and the rule fires immediately, which is the old behaviour and is what rules created before this field existed still do.

Choosing where a rule delivers

Pick one or more channels under Notify channels. A rule with no channel picked goes to every enabled channel. While the selection is empty the form says so in a warning that gives the number of enabled channels and names each one, and the rule list marks every such rule with "ALL n enabled channels" and the same names, so a rule you are only testing does not page whoever is on call. Narrow it before you save it. A rule with channels picked shows those channels on its row instead.

Pointing a rule at ONE workload

A rule is scoped to a namespace and a resource kind. Give it a workload target as well and it fires for exactly one workload — "the recommendations deployment crash-looped", not "some Deployment in this namespace did".

The target is exact identity: namespace, kind and name. It is not a substring, so recommendations does not quietly also mean recommendations-worker. Pods are matched by walking their ownerReferences (Pod → ReplicaSet → Deployment / StatefulSet / DaemonSet / Job / CronJob), which means you target the workload that owns the pods rather than pod names that change on every rollout.

Not every condition can be targeted, and the ones that cannot refuse. Seven accept a target: pod restart threshold, pod phase match, pod not ready, log pattern, deployment degraded, job failed, and event pattern. Seven reject it with an error rather than save a rule whose stated scope would be a lie — node condition (a Node is not a namespaced workload), PVC unbound (an unbound claim is by definition attached to nothing yet), metric threshold (the scope lives inside your PromQL), scan severity threshold (a per-namespace finding count), system event (KubeManta's own audit rows, which name no cluster object), application health (already targeted, by application), and SLO burn rate (already targeted, by the SLO).

Leaving the target empty is the old behaviour, and is what every rule created before this field existed still does.

The namespace is a list, not a text box

A rule's namespace is chosen from the namespaces the cluster actually has, rather than typed. A namespace that does not exist would save a rule matching nothing: no error, a healthy-looking row, and an alert that never arrives.

A saved rule keeps its own namespace as an option even if that namespace is gone or hidden, so opening an old rule to change its cooldown cannot silently re-scope it to somewhere else.

Setup

Reach Alerts Manager from the SIGNALS group in the sidebar. Three sub-tabs cover the surface: Alerts, the live feed and the history of everything that fired; Rules, where rules are created and edited; and Integrations, destination configuration. To create a rule, go to the Rules tab, choose + New Rule — or one of the four templates above the list, which opens the same form already filled in — then pick a condition type, set thresholds and a cooldown, and use Test on the rule to dry-run it before enabling. Test evaluates the rule against the live cluster and reports what it would fire on; it never delivers anything, so it is safe to run against a configured Slack or PagerDuty. To configure a destination, go to Integrations, pick a provider card, enter credentials, choose Save changes, then Send test alert. An admin clears the history from the Alerts tab.

Asking KubeManta things from Slack

Slack outbound — alerts arriving in a channel — is the destination described above and works on every tier. Slack inbound, asking KubeManta questions from a channel, is separate, Pro, and off by default, because it means cluster state leaves for a third party.

A Free install can still save its Slack app and bot tokens with the integration switched off, so the setup can be prepared before buying; turning it on answers 402 license_required. If the tokens are set by Helm values on a Free install, KubeManta does not connect and says why — the Slack inbound status (GET /integrations/slack-inbound) reads "Slack inbound is a Pro feature" rather than pretending the tokens are missing.

Set it up in Alerts Manager → Integrations → Slack inbound (admins only). Create a Slack app with Socket Mode enabled, then paste its Socket Mode App token (xapp-…, with connections:write) and its Bot token (xoxb-…, used to post replies), switch it on and Save changes. It takes effect without a restart, and the status line under the switch says whether it is connected, reconnecting, waiting for a licence, or cannot reach slack.com.

Tokens are write-only: once saved, the screen shows only that a token is stored, never the token. Leave a field blank to keep the stored one — rotating a token is pasting the new one and saving.

The same settings can be seeded from Helm values instead:

--set slack.inbound.enabled=true \
--set slack.inbound.appToken=xapp-…   # Socket Mode app token (connections:write)
--set slack.inbound.botToken=xoxb-…   # bot token, used to post replies

Both tokens are stored in KubeManta's Kubernetes Secret, never as plain environment on the Deployment. Saving in the product replaces the Helm-seeded values for that install.

Socket Mode means one OUTBOUND WebSocket. There is no ingress to open, no certificate to obtain and no unauthenticated route added, so it works on a cluster with no public entry point. It is useless in a true air-gap — slack.com is unreachable by definition — and KubeManta says so instead of retrying: with air-gap mode on it does not dial at all.

Who can do what is not configured here. Each Slack user acts as their own KubeManta account, and that account's role is read live on every message — so a viewer's Slack account can only read, and an admin who is demoted loses admin on their next message. Deactivating the KubeManta account cuts off its Slack access at once.

How Slack users are linked. The first time someone messages KubeManta, KubeManta asks Slack for that person's profile and links them to the KubeManta account with the same email — but only when all of these hold:

  • Slack reports the email as verified. An address someone typed into their profile without Slack confirming it never links.
  • The person belongs to the workspace the bot is installed in. Guests from another organisation in a shared channel are not linked.
  • Exactly one active KubeManta account (local or single sign-on) has that email, compared without regard to case. A deactivated account never links, and if two active accounts share the email, neither is linked.

Linking never creates a KubeManta account. The Slack app needs the users:read and users:read.email bot scopes for this; without them nobody is linked, and the Slack inbound screen says which scope is missing. A Slack user who is not linked is refused before anything is read or any AI is used, and is told to check that their Slack email is verified and matches their KubeManta account, or to ask an admin.

Admins manage links under Linked Slack users on the same screen (Alerts Manager → Integrations → Slack inbound):

  • Link automatically (the default) links a matching Slack user on their first message. Require approval holds the same match as waiting until an admin approves it; nobody can use KubeManta from Slack before that. Changing this does not affect existing links.
  • Approve or Deny a waiting link, Revoke a live one, and Restore a revoked one. A revoked link stays revoked — the person writing to KubeManta again does not re-link them, in either mode. When you approve or restore a link, KubeManta checks the email against the KubeManta account as it is at that moment.

Links, approvals, revocations and changes to the linking mode are recorded in the audit log, under the name of the person who made each one.

Commands are read-only by construction. KubeManta never changes your cluster in response to a chat message; actions arrive as an approval you confirm. Ask it for Cluster Health, /pods <namespace>, /deployments <namespace>, /nodes, /warnings [namespace] or /help. These fixed commands do not use AI. In a channel, mention the app (@KubeManta cluster health); in a direct message, just type.

Questions in your own words. Anything that is not one of the commands above — "why is checkout crash-looping?" — is answered by the same AI assistant as the dashboard, using the AI provider configured in Admin → AI, with the same guardrails: the AI kill switch, data residency, cost caps, the egress allowlist and prompt auditing all apply. It can only read the cluster from Slack. Questions need the AI provider as well as Slack inbound, and count against the same AI request limit as the dashboard (10 a minute per linked Slack account by default, AI_RATE_LIMIT_PER_MIN). A message from an unlinked Slack account is refused before any AI is used.

What leaves for Slack. An answer is cluster information — pod names, namespaces, events, statuses and whatever the assistant quotes from logs — and posting it sends that text to Slack's servers, in addition to your AI provider. KubeManta applies its secret redaction to every message before it is sent, the same redaction applied to what the AI reads. In a channel the answer is shown only to the person who asked; a direct message is already private.

Approving a change from Slack. When the assistant decides a change would help, nothing runs. The reply shows the exact change as a plan, with an Approve and apply button for KubeManta admins (others see that an admin must apply it). Pressing the button is the same approval as the dashboard's, with the same checks: the person pressing must be linked to a KubeManta admin account (from Slack this is admin-only, even for the restarts and scales a developer can approve in the dashboard), the write circuit breaker and the per-person write limit apply, and each approval works once — pressing it again, or after it expires, changes nothing. The audit log records the change under the name of the person who pressed, with one correlation ID from the approval to its outcome. Typing "approve" or "delete the deployment" is never an approval: only the button applies a change. Buttons need Interactivity enabled on the Slack app; with Socket Mode no request URL is needed. The terminal is never reachable from Slack.

What Free includes, and where Pro starts

Alerting is part of the Free tier, and the number of rules is unlimited. Write as many as your cluster needs, delivered to Slack, Telegram or email, each alert carrying the cluster context described above.

Pro adds the operational integrations (PagerDuty, Datadog, CloudWatch and the generic Webhook), retained firing history, the AI diagnosis that follows an alert, incident tickets in Jira or Trello, and Slack inbound.

A lapse never stops alerting that is already running. Being downgraded must not quietly stop the alert you depend on, so when a Pro or Enterprise licence lapses:

  • Every rule keeps evaluating, and every destination that is switched on keeps delivering — including PagerDuty, Datadog, CloudWatch and the Webhook. KubeManta does not check the licence at delivery time.
  • You can still edit a Pro destination that is on (a rotated routing key, a new webhook URL) and save the rest of the Integrations form, and you can switch any destination off.
  • What needs Pro again is switching a Pro destination on — including switching one back on after turning it off — and Send test alert to a Pro destination. Configuration for a Pro destination can always be saved while it is switched off, so an unrelated edit never fails for a reason the form cannot explain.
  • The paid work that happens after an alert stops: the AI diagnosis is not produced, new incident tickets are not opened, and the firing history is not shown, until the licence is renewed. The alert itself is still delivered.

The same rule holds for a configuration file imported from another install: a Pro destination arrives switched off on an install without Pro, unless it was already on here.

Destinations set by Helm values work on every plan. Three destinations can be given at install time instead of in Alerts Manager: alerting.slackWebhookUrl (Slack), alerting.pagerdutyRoutingKey (PagerDuty) and alerting.webhookUrl (a generic JSON POST for each fired alert). They are provided by whoever runs the Helm release rather than switched on in the product, so they deliver whatever the licence, on Free too. PagerDuty and Slack set this way appear under Integrations as switched on, and can be switched off there.

Delivery limits, and what happens at the cap

Two limits protect whoever receives your alerts, and they apply on every tier — they exist to stop a misconfigured rule flooding someone else's endpoint, not to sell you anything.

  • A cooldown floor of 60 seconds. The evaluator runs every 30s, so a rule with a shorter cooldown re-notifies on almost every tick for as long as the condition holds. A rule saved with less is refused, with the floor named in the message, rather than quietly rewritten — a rule that reads as one thing and behaves as another is worse than one that will not save. A rule saved before the floor existed is held to it too: it waits at least 60 seconds between notifications, and the next time it is saved — including switching it on or off — its cooldown is stored as 60 so the form shows what it does.
  • Delivery caps per hour: 60 for a single rule, 100 for a single integration. One broad rule over a large namespace is the case these exist for.

At the cap, nothing is silently dropped and no rule is switched off. A disabled alert is its own incident. Instead the delivery is recorded with status capped, in the same receipt trail as every sent and failed one, and a warning appears in the Activity feed naming the rule or integration that hit the limit. The firing history stays complete: the cap applies to notification, never to detection, so the record of what happened is intact whether or not the message went out.

If the database is briefly unavailable the caps fail open and delivery continues uncapped. Silencing alerts because a counter could not be read would turn a storage blip into an outage nobody is told about.

One page per incident

When one failure takes several things down with it — a node going bad and taking twelve pods, say — each affected pod would otherwise page on its own. With incident grouping (on by default), an alert that shares a blast radius with an alert that already paged is recorded, with its evidence, but does not send another page. Related means:

  • the same resource, alerted on by another rule;
  • the same workload (for example, two pods of one Deployment);
  • the same node — and a node's own alert is never hidden under one of its pods' pages; its pods group under it instead;
  • resources directly connected in the cluster graph, within two hops — pods behind the same Service, pods sharing a PersistentVolumeClaim. A shared ConfigMap or Secret does not count.

Every grouped alert still appears in the firing history (marked grouped · no page), and each channel it would have gone to gets a delivery receipt with status grouped that says why. The incident report lists the grouped alerts and the reason for each. A group stays open while any of its alerts belongs to an open incident, or for 30 minutes after its most recent alert (INCIDENT_GROUP_WINDOW_SECS).

Two things still page: a rule re-firing on the same resource after its cooldown (the reminder you configured), and an alert more severe than the one that paged — an escalation is news.

What grouping does not do. It is structural, not general correlation. Workloads broken by the same external cause — a database, DNS or cloud-provider outage — are not connected in the cluster, so each still pages on its own. When KubeManta cannot tell whether an alert is related (the pod cannot be read, or the cluster graph cannot be built in time), the alert pages.

Administrators can switch grouping off under Alerts Manager → Rules → One page per incident; every change is recorded in the audit trail. With it off, every alert that fires sends its own page, as before.

Incident tickets in Jira or Trello (Pro)

KubeManta can open a ticket for each incident it detects — a Jira issue or a Trello card — and keep that one ticket up to date for the incident's whole life. It is not another alert channel: an alert channel gets a message every time a rule fires, while a ticket follows the incident, so one outage is one ticket no matter how many alerts it raises. Your alert channels keep working exactly as before.

What happens to the ticket:

  • When the incident is detected, a ticket is opened in the project or list you chose. It carries the namespace, workload, reason and severity, what the cluster reports about the failure, recent events and changes, and the last log lines — the same information an alert carries — and a link back to KubeManta if you set its address.
  • If the incident recurs, KubeManta adds a comment rather than opening a new ticket, at most once per comment interval (30 minutes by default); recurrences in between are summarised in the next comment.
  • When the cluster reports the workload healthy again, KubeManta adds a resolution comment and closes the ticket — in Jira with the transition you name (Done by default), in Trello by moving the card to the list you choose. It waits ten minutes first, because an incident that comes back in that time is the same incident.
  • If someone on your team has already moved or closed the ticket, KubeManta leaves it alone from then on. It never overrides a person.

What leaves your cluster. Turning this on sends incident details to Jira or Trello: namespace and workload names, what Kubernetes reports about the failure, recent events and changes, and the last log lines. Secrets are redacted before anything is sent, and each ticket is size-limited. Nothing in a ticket is ever used to change your cluster.

Setting it up. Administrators configure it under Alerts Manager → Integrations → Incident tickets:

  • Jira — your Jira address, a user or email and API token (Jira Cloud) or a personal access token (Jira Server / Data Center), the project key and issue type, the Resolve transition, and any fields your project requires (Required fields (JSON)).
  • Trello — an API key and token, the board, the list new cards go to, and optionally the List for resolved cards.
  • Which incidents open a ticket: critical, warning or both (critical only by default), and which namespaces (every namespace KubeManta shows, by default). KubeManta's own namespace is never ticketed.

Send test ticket opens an example ticket exactly as a real incident would and closes it straight away, so a passing test proves the whole round trip — required fields and the close step included. Check connection only reads. Tokens are stored encrypted and are never shown again; leave a token field blank to keep the one already saved. Every change and every test is recorded in the audit trail.

Incidents that were already open when you switch ticketing on are not ticketed; every incident detected afterwards is. If you use a destination allowlist for alert webhooks, your Jira address must be on it.

When a ticket cannot be created, you are told rather than left guessing: the incident itself shows the ticket as failed with Jira's or Trello's own explanation (for example, a missing required field), the Activity feed records it, and the Incident tickets screen shows the latest failure. A refusal is retried once you save the configuration again; a temporary outage on the tracker's side is retried automatically, with increasing waits.

Incident tickets are part of Pro. A Free install can prepare the configuration but not turn it on; if a licence lapses, new tickets stop and the configuration is kept.

Troubleshooting

Because detection and delivery both run inside the same KubeManta process, a dead agent means no alerts fire and nothing announces that fact from inside the product — the honest failure mode of a single-process alerting system. Enabling the alert heartbeat (alerts.heartbeat.enabled, off by default) emits a low-severity alert every hour (alerts.heartbeat.intervalSecs, default 3600s) through your configured integrations; because you alert on its absence rather than its presence, it's the one signal that can survive the process it's reporting on.

The heartbeat reports what it can actually check. It carries the age of the last completed rule evaluation, and if that goes stale — or has never happened — it escalates to a critical "KubeManta Alerting STALLED" message instead of arriving as usual. That case is not hypothetical: rule evaluation can stop while the process stays up and healthy, and a heartbeat that kept saying "running and evaluating rules" through it would be worse than no heartbeat, because you would trust it. If a rule appears configured correctly but never fires, use the Test action on the rule to dry-run the condition directly against current cluster state rather than waiting for the 30-second evaluator, which narrows down whether the condition itself is wrong or the delivery integration is. If one integration is silent while others deliver correctly, use that integration's own Send test alert — each destination is attempted independently, so a single misconfigured one degrades on its own without affecting the rest.

When an alert should have reached you and did not, read its delivery receipts before changing any configuration. They separate the three cases that look identical from the outside: the alert never fired (no receipts at all), it fired and the channel refused it (a failed receipt carrying the status and the provider's own message), or it fired and the channel was never tried (a skipped receipt, which names the reason — either the integration is disabled, or the rule's own channel selection did not include it). Only the second case is a credentials problem, and only the first is a rules problem.

Generated from KubeManta 1.5.0 — this page is rendered from the product's own documentation, so it cannot drift from what ships. Manifest built 2026-11-03T12:53:14Z.