Niro docs

Overview

Niro automatically detects operational incidents by analyzing status data from your fleet. When a problem is detected, an incident is opened. When the condition clears, the incident is resolved.

Automatic detection

Niro continuously evaluates cluster data for crash loops, offline clusters, node failures, and more.

Smart notifications

Route alerts to Slack, Discord, PagerDuty, or a custom webhook with per-channel severity filters.

AI investigation

One-click root cause analysis gathers logs and cluster state to explain what went wrong.

Incident lifecycle

Incidents open when conditions fire and resolve automatically when they clear.

Detected incident types

Type	Condition
Cluster offline	No status update received within the expected window
Pod crash-looping	A pod has restarted more than a threshold number of times in a recent window
Node not ready	A node has stopped reporting as healthy
Deployment failed	A deployment apply resulted in a Failed or Partial status
Drift detected	Live cluster state diverges from the repo’s desired state
Probe unhealthy	A recent probe warning accompanies a workload with no ready or available replicas
Image pull error	A pod can’t pull its container image

Each incident has a stable fingerprint based on cluster, type, and scope. Niro won’t fire duplicate incidents for the same ongoing condition.

Probe warnings and workload availability

A single probe timeout stays a warning in the timeline. If the workload remains available, it creates no incident, notification, or automatic investigation. For example, incident #51’s isolated liveness timeout on gateway-api would stay quiet while its API remains healthy. Seven warnings spread across hours do not establish seven consecutive failures. Kubernetes applies the pod’s configured probe thresholds. Niro uses the resulting health observations; it does not count warning events as failed probe attempts.

Observation	Probe incident behavior
At least one ready or available replica	Quiet, including partial replica loss and progressing rollouts
Positive desired count, zero ready and available replicas, and a matching recent probe warning	Opens on the first qualifying sweep, with 0 seconds of additional debounce
Available capacity returns, or desired count becomes zero	Resolves on the next qualifying sweep
Missing, stale, partial, malformed, or ambiguous health evidence	Unknown: does not open or resolve a probe incident

Deployment, DaemonSet, and standalone ReplicaSet use their reported ready and available counts. StatefulSet uses ready replicas as a serving-capacity proxy. A bare Running Pod uses its Ready condition; terminal bare Pods are inactive. Other controller kinds do not currently qualify probe incidents. These are Kubernetes availability proxies, not direct measurements of application traffic or database quorum. There is no separate startup grace period. A newly observed workload with zero capacity and matching probe evidence can qualify before it has served traffic. A workload with even one ready replica stays quiet while availability stabilizes. Actual notification delivery still follows your channel severity settings; qualified probe incidents retain severity warning. Niro requires heartbeat and catalog evidence newer than 120 seconds. An explicitly unchanged catalog can remain valid even when individual resource rows are older. Agents without sufficient catalog evidence keep warning history but cannot qualify this detector. An unresolved incident with unknown evidence remains open; it is not evidence of confirmed recovery. Existing legacy probe incidents are rechecked against current health. Healthy legacy incidents close without starting a resolution investigation. Unsent false-positive notifications are suppressed, while channels with a sent or attempted firing delivery receive a resolution to close the external alert. Previously delivered notifications cannot be recalled. Existing historical incidents and investigations remain available for review. The corrected behavior is fully effective after all older control-plane replicas have drained.

Incident lifecycle

Condition detected

Niro detects the condition from incoming cluster data.

Incident opened

An incident is created in the Alerts page. Notifications are sent to all matching channels.

Investigation (optional)

If auto-investigation is enabled, Niro runs an AI root-cause analysis in the background.

Incident resolved

When the condition clears, Niro resolves the incident and sends resolution notifications.

You can’t manually delete a firing incident — if the condition is still active, Niro would reopen it immediately. Resolved incidents can be deleted from the Alerts page.

Notification channels

Discord

FreeNiro posts a formatted message to a Discord channel via webhook.Setup:

In Discord: Server Settings → Integrations → Webhooks → New Webhook
Copy the webhook URL
In Niro: Settings → Alerts → Add Discord channel

Slack

ProNiro posts a formatted message to a Slack channel via an Incoming Webhook.Setup:

Create an Incoming Webhook in your Slack workspace
In Niro: Settings → Alerts → Add Slack channel with the webhook URL

PagerDuty

ProNiro creates PagerDuty incidents via the Events API v2, sending trigger on open and resolve on close.Setup:

In PagerDuty: create a service and copy its Integration Key
In Niro: Settings → Alerts → Add PagerDuty channel with the Integration Key

Webhook

ProNiro POSTs a JSON payload to your URL on every incident state change.

{
  "event": "incident.opened",
  "incident": {
    "id": "inc_abc123",
    "type": "pod_crash_looping",
    "severity": "high",
    "cluster": "my-cluster",
    "scope": "default/my-app-5d9b8c-xyz",
    "fired_at": "2024-01-15T10:30:00Z"
  },
  "org": "my-org"
}

Events: incident.opened · incident.resolved

Incident.io

EnterpriseNiro creates Incident.io incidents directly via their API.

Acknowledging incidents

You can acknowledge a firing incident to signal that your team is aware and investigating. Acknowledging an incident doesn’t resolve it — it continues to track the condition and resolves automatically when the condition clears. Acknowledgements appear in the incident timeline.

Minimum severity filter

Each channel has a minimum severity setting — incidents below the threshold don’t trigger that channel.

Severity	Typical use
Info	Logging webhook — capture everything
Warning	Slack — catch problems early
Error	On-call Slack — significant failures only
Critical	PagerDuty — severe outages requiring immediate response

Auto-investigation

Niro can automatically run an AI investigation when incidents change state. Configure in Settings → Auto-investigation:

Mode	When investigation runs
`off`	Never — manual only
`firing`	When an incident opens
`resolved`	When an incident resolves
`both`	On both open and close

firing mode is most useful — you get root-cause analysis the moment something breaks, before you’ve opened the dashboard.

Available on Pro and above.

AI Investigation

What the investigator analyzes and what it returns.

Monitor Your Fleet

Pod inventory and cluster health views.

Plans

Notification channel availability by plan.

Multi-tenancy

Org-level alert channel configuration.

Start

Concepts

Guides

Features

Integrations

Reference

Alerts & Incidents

Overview

Automatic detection

Smart notifications

AI investigation

Incident lifecycle

Detected incident types

Probe warnings and workload availability

Incident lifecycle

Notification channels

Acknowledging incidents

Minimum severity filter

Auto-investigation

AI Investigation

Monitor Your Fleet

Plans

Multi-tenancy

​Overview

Automatic detection

Smart notifications

AI investigation

Incident lifecycle

​Detected incident types

​Probe warnings and workload availability

​Incident lifecycle

​Notification channels

​Acknowledging incidents

​Minimum severity filter

​Auto-investigation

​Related

AI Investigation

Monitor Your Fleet

Plans

Multi-tenancy

Overview

Detected incident types

Probe warnings and workload availability

Incident lifecycle

Notification channels

Acknowledging incidents

Minimum severity filter

Auto-investigation

Related