Concepts

Scope and limits

What AlertINT does, what it deliberately won't do, and its known weak spots.

The boundaries below are design decisions. Knowing them up front sets the right expectations.

Does and doesn't#

AlertINT does	AlertINT doesn't
Read alerts, metrics, logs, errors, and changes	Change your infrastructure
Correlate, triage, and verify	Remediate, silence, or re-route alerts
Track each Situation to recovery, or say recovery is unconfirmed	Run scripts or runbooks
Post one message per Situation to Slack	Open tickets or page on-call tools
Send selected Situation changes to ntfy	Provide an on-call rota, acknowledgement or escalation policy
Serve context to your agent over MCP	Include a web UI (the self-hosted agent runs on config, MCP, and Slack)
Store your verdicts, notes, and expected-behaviour judgments in its own state	Write anywhere outside its own state

Read-only toward your systems. Every connector only queries.
Self-hosted. Alert data stays on your machine, except evidence and messages sent to configured LLM and notification services. ntfy.sh receives the selected message content; a self-hosted ntfy endpoint can keep that delivery inside your network. Use access-controlled topics.
Fair Source. FSL-1.1-ALv2: free to use, modify, and self-host at any scale. Each release becomes Apache 2.0 two years after it ships. Paid tiers sit on top, never inside the engine: a hosted control plane for teams (fleet management, SSO/RBAC, audit retention), carrying metadata only.

Situations do	Situations don't
Group Incidents with the same group key into one episode, across restarts	Group Incidents with different group keys
Decide whether to investigate, and how urgent it is	Ask you questions on their own
Accept "this is expected" for one Situation, or a schedule for a proven Zabbix or Alertmanager rule	Infer schedules from webhook labels alone
Let "expected" lower urgency and change wording	Stop monitoring, investigation, or recovery tracking
Use advisory profiles to widen which checks run	Let a profile mark alerts firing or resolved, interrupt the channel, or post to Slack

A Situation not yet assessed shows assessment: null over MCP, never a placeholder.

Problem	What to do
Volatile grouping labels. A label like `pod=web-68f9c-xk2pq` in the group key creates one Incident per value.	Group on stable labels (`service`, `namespace`, `alertname`) in your Alertmanager route or `correlator.group_labels`.
Flapping inside the window. An alert that fires, resolves, and re-fires within the correlation window shows both `firing` and `resolved` in the evidence.	Raise `correlator.window_seconds` past the flap cycle, or set Alertmanager's `repeat_interval`.
Confidence isn't calibrated. It's the model's own certainty: 0.9 doesn't mean 90% accurate.	Treat Findings as advisory. Review before acting.
`min_alerts` above 1 skips lone alerts. A single alert gets no Finding.	Keep the default `1`; control noise with `notify.slack.min_severity`.
Automatic checks are bounded. Trends, comparisons, and custom PromQL are up to you or your agent.	Ask your agent for service-level queries (CPU, memory, latency, errors) around the window.
Escalations don't re-analyze. A recurring condition that gets worse is recorded, not re-triaged, while its Situation is open.	Watch `recurred ×N`; see Incident memory.

Being explored:

Pattern and slow-burn rollups (repeats over hours or days)
More skills beyond acute triage
Cost metering and budget caps
SSO/RBAC and team fleet management (the hosted control plane)
Pull-based Alertmanager reconciliation on startup
A hosted option (planned, not available): we run and maintain the same engine for you, a small proxy in your network forwards alerts without firewall changes, and a web UI manages it

Remediation, if it ever lands, will require explicit operator approval.