Detection & baselines

Inkvo doesn't fire on static thresholds you have to guess and maintain. It learns each service's normal behavior and alerts on deviations that matter — adapting as your traffic shifts.

How baselines form

For the first 24 hours after a service starts reporting, Inkvo builds a per-service, per-environment model of latency, error rate, throughput, and saturation — including their daily and weekly seasonality. A 9am traffic ramp isn't an anomaly; a 3am one might be.

What counts as a deviation

• Latency: p50/p95/p99 drifting outside the learned band
• Errors: 4xx/5xx rate above the seasonal expectation
• Throughput: sudden drop (a silent failure) or spike
• Saturation: CPU, memory, connection-pool, queue depth nearing limits

Tuning sensitivity

Each service has a sensitivity dial and optional per-signal weights in Settings → Detection. Strict in prod, relaxed in staging is the default. Marking an incident as noise feeds back into the model automatically.

{
  "service": "payments-svc",
  "environment": "production",
  "sensitivity": "strict",
  "weights": { "latency": 1.0, "errors": 1.0, "saturation": 0.5 }
}