One of the most common questions we get when teams connect Streamforge for the first time is: where do I start? You have 40 Kafka topics. You cannot put the same monitoring sensitivity on all of them at once. You need to triage: which topics deserve anomaly detection first, how sensitive should the baseline be, and what alert routing makes sense for each category.
This guide is what we tell new teams. It is not a comprehensive product tutorial (that is in the docs). It is the reasoning behind the configuration choices, so you understand why the prioritization is what it is and can adapt it to your specific pipeline.
The Risk Matrix for Topic Prioritization
Before configuring anything, do a quick categorization of your topics along two axes: downstream impact severity and schema volatility.
Downstream impact severity: if this topic delivers wrong data for one hour, what breaks? For a financial transaction topic, the answer is "ledger entries are wrong, reconciliation fails, potential financial loss." For an analytics events topic, the answer is "dashboards will be slightly off until tomorrow's refresh." These are in different risk categories and deserve different monitoring sensitivity.
Schema volatility: how often do producers on this topic change their schema? Topics fed by a stable internal service that has not changed its event format in six months need less sensitive monitoring than topics fed by an active product team shipping multiple times per week. High-volatility topics have more legitimate schema evolution, which means the anomaly detection baseline needs room to adapt to intentional changes without false-positiving constantly.
The combination gives you four quadrants: high impact + high volatility (highest monitoring priority, but tune sensitivity carefully to account for frequent legitimate changes), high impact + low volatility (easy wins: tight monitoring, few false positives), low impact + high volatility (monitor but keep alert threshold loose), low impact + low volatility (defer or use minimal monitoring).
Tier 1: Topics That Feed Financial or Transaction Systems
Payment events, order confirmation events, inventory adjustment events, anything that writes to a financial ledger or affects a business transaction record. These get the tightest monitoring configuration.
In Schema Guard's configuration, for these topics you want:
- Null rate alerts at 1% threshold on any field that was previously never null (the baseline will learn null rates from production traffic; for fields with a 0% historical null rate, any null becomes an immediate alert)
- Value range monitoring on amount, quantity, and price fields with a tight band (we recommend 3 standard deviations from the rolling baseline for these fields)
- Type change alerts enabled (any field showing a type distribution shift pages immediately)
- DLQ routing with field-level diff on every quarantined event
Alert routing for Tier 1 topics should go directly to your on-call engineer, not just a Slack channel. The speed-to-detect matters because bad events in these topics can cascade quickly.
We are not suggesting that every potential anomaly in a Tier 1 topic is a real problem. False positives still happen, especially during the baseline warmup period. But the cost of a missed anomaly here is high enough that you want low alert thresholds and a reliable escalation path.
Tier 2: Topics That Feed User-Facing Features
Topics that power real-time user experiences: recommendation events, notification triggers, user preference events, search index updates. Wrong data in these topics shows up as wrong user experience: a user sees irrelevant recommendations, receives a notification they should not, gets wrong search results. This is visible and customer-impacting but usually recoverable and not financially material.
For Tier 2 topics, configure:
- Null rate alerts at 5% threshold on required fields (more tolerant of occasional nulls than Tier 1)
- Value range monitoring on fields with known domains (category IDs, score values, status enums)
- Type change alerts enabled
- DLQ routing but alert routing to Slack rather than pager
The baseline warmup period for Tier 2 topics can be a full week before you enable alerting. User-facing feature topics often have high daily and weekly seasonality patterns, and the baseline needs to capture at least one full weekly cycle to avoid false positives around regular traffic patterns like weekend drops and Monday spikes.
Tier 3: Analytics and Reporting Topics
Topics that feed data warehouses, BI tools, or batch analytics jobs. Wrong data here shows up in reports and dashboards, typically caught during review cycles. The time pressure is lower. You can usually tolerate a few hours of bad data before correction.
For Tier 3 topics, start with a longer baseline period (two weeks minimum) and lighter monitoring: anomaly alerts at 10% threshold on key dimension fields (user ID, product ID, session ID), no pager routing, weekly digest or Slack notification only.
The value of monitoring analytics topics is not catching emergencies. It is catching the slow drift that makes analytics unreliable over time: a session ID field that gradually starts containing null values because of a bug in a mobile client, a revenue field that shifts from net to gross because someone changed how a calculation service emits its output. These are important to catch but not urgent.
Starting the Baseline Period
When you first connect Streamforge to a topic, the monitoring starts in observation mode. No alerts fire. The system is building the field-level baseline: learning the type distribution of each field, the null rate per field, the value range for numeric fields, and the cardinality of string fields that function as enumerations.
How long this takes depends on volume. For a topic receiving tens of thousands of events per hour, the baseline is statistically meaningful within 24-48 hours. For a topic receiving a few hundred events per day, allow a full week before enabling alerts. The minimum sample size before the baseline is considered stable is configurable in Schema Guard settings; we default to 10,000 events per field, which means low-volume topics take longer to warm up.
During the baseline period, we recommend reviewing the baseline metrics manually once before enabling alerts. Go to the Schema Guard topic view, look at the field-level stats, and sanity-check whether the distributions look reasonable. If you see a field showing 30% null rate that you expected to be required, that is useful to know before the baseline locks in, because it might indicate a pre-existing data quality issue rather than a future anomaly.
Alert Sensitivity Tuning: Start Loose, Tighten Later
The most common mistake new teams make is starting with very tight alert thresholds and then getting alert fatigue during the first two weeks as the baseline adapts to traffic patterns the initial warmup did not fully capture. This causes teams to disable alerts prematurely.
We recommend starting at the default sensitivity settings (which are deliberately conservative) and tightening per-topic once you have had a week of alert activity to review. If Tier 1 topic alerts are firing for reasons that turn out to be false positives, investigate why before tightening. If the false positive is from a legitimate weekly traffic pattern the baseline did not fully capture, extend the warmup period rather than loosening the threshold.
Tight thresholds on the right topics are the goal. Loose thresholds everywhere because you got tired of false positives is not. The path to tight thresholds is a good baseline, not jumping straight to aggressive detection on day one.