SynaptoreAI lab

Explore use cases

One workflow. Different operations.

Each example follows the same path: collect the signals you already have, detect what departs from usual behaviour in logs and metrics, then connect the observations into a finding your team can examine.

Use case 02 · Digital services

Checkout slows down, then starts failing.

Customers see slow order pages and failed payments. Payment, inventory and the API gateway all report errors within seconds of each other. Every team sees its own symptom. Which change came first?

01 · Collect

Signals you already have.

Logs and metrics are gathered from the systems that produce them, without changing how those systems run.

  • AUTH-SVCAuthentication · Service
  • API-GWAPI gateway · Edge
  • PAYMENT-SVCPayments · Service
  • INVENTORY-SVCInventory · Service
  • DATABASEShared database · Data

Log stream

  1. AUTH-SVCUser login successful userId=8342
  2. API-GWGET /api/orders 200 duration=45ms
  3. PAYMENT-SVCPayment authorized orderId=9832
  4. AUTH-SVCFailed login attempt, repeated 312 times in 60s
  5. API-GWGET /api/orders 500 duration=3200ms
  6. PAYMENT-SVCPayment service timeout
  7. INVENTORY-SVCError connecting to DB
  8. DATABASEConnection pool exhausted (100/100)
  9. API-GWPOST /api/checkout 503 duration=5020ms

02 · Detect in logs

Unusual log patterns stand out.

Log models learn the usual events and sequences for each source, then flag lines that depart from that reference.

6 of 9 lines flagged

Log stream with detected anomalies

  1. AUTH-SVCUser login successful userId=8342
  2. API-GWGET /api/orders 200 duration=45ms
  3. PAYMENT-SVCPayment authorized orderId=9832
  4. AUTH-SVCFailed login attempt, repeated 312 times in 60sUnusual volume
  5. API-GWGET /api/orders 500 duration=3200msError and latency
  6. PAYMENT-SVCPayment service timeoutRare event
  7. INVENTORY-SVCError connecting to DBRare event
  8. DATABASEConnection pool exhausted (100/100)Capacity limit
  9. API-GWPOST /api/checkout 503 duration=5020msCustomer impact

03 · Detect in metrics

Metrics leave their usual range.

Metrics models look across several measurements over time and mark the windows where behaviour changes.

  • Failed logins per minuteAUTH-SVC

    Burst starts first

  • Active DB connectionsDATABASE

    Pool at 100%

  • Payment latency p95PAYMENT-SVC

    Timeouts

  • API 5xx rateAPI-GW

    5xx errors

04 · Connect & inform

A lead your team can test.

Anomalies from logs and metrics are placed in order and combined with operational context into one finding.

Context added

  • Service map
  • Deployments
  • Runbooks

Observations in order

  1. Failed logins on AUTH-SVC jump far above usual
  2. Active database connections climb
  3. Payment timeouts and API 500 errors begin
  4. Pool reports 100/100; inventory cannot connect
  5. Checkout requests fail with 503

Illustrative operator finding

Likely lead to testDatabase connection pool exhaustion, driven by a burst of authentication traffic.

Why this lead?
The login burst and the connection climb start together, before any service fails. AUTH-SVC, PAYMENT-SVC and INVENTORY-SVC share the same pool, so the later errors fit a capacity limit rather than three separate faults.
Suggested checks
  1. Break down pool usage by client service during the window.
  2. Check the origin of the failed logins and whether each attempt holds a connection.
  3. Compare with recent deployments and pool configuration changes.
Alternative to check
A slow query or lock on the database could also hold connections open. Check query latency and locks in the same window.

Illustrative use case. Records, timings and values are invented to explain the intended workflow. Timing and relationships suggest a lead; they do not prove its cause.

Use case 03 · Cloud platforms

A routine release slows the order API.

A new version of a service rolls out on Kubernetes. Twenty minutes later latency rises and pods restart, but no alert names the release. Is it traffic, the cluster or the change?

01 · Collect

Signals you already have.

Logs and metrics are gathered from the systems that produce them, without changing how those systems run.

  • CI/CDDelivery pipeline · Change
  • K8SCluster events · Platform
  • ORDERS-APIOrders service · Service
  • INGRESSIngress gateway · Edge

Log stream

  1. CI/CDRollout started: orders-api v2.14.0 (3 replicas)
  2. K8SPod orders-api-7d9f4-x2kqp Started
  3. ORDERS-APIGET /orders 200 duration=48ms
  4. CI/CDRollout complete: orders-api v2.14.0
  5. ORDERS-APICache client: response buffer grew to 512MB
  6. K8SPod orders-api-7d9f4-x2kqp OOMKilled (limit 1Gi)
  7. K8SBack-off restarting failed container orders-api
  8. INGRESSupstream timed out GET /orders 504

02 · Detect in logs

Unusual log patterns stand out.

Log models learn the usual events and sequences for each source, then flag lines that depart from that reference.

4 of 8 lines flagged

Log stream with detected anomalies

  1. CI/CDRollout started: orders-api v2.14.0 (3 replicas)
  2. K8SPod orders-api-7d9f4-x2kqp Started
  3. ORDERS-APIGET /orders 200 duration=48ms
  4. CI/CDRollout complete: orders-api v2.14.0
  5. ORDERS-APICache client: response buffer grew to 512MBNew message type
  6. K8SPod orders-api-7d9f4-x2kqp OOMKilled (limit 1Gi)Rare event
  7. K8SBack-off restarting failed container orders-apiRepeated
  8. INGRESSupstream timed out GET /orders 504Error and latency

03 · Detect in metrics

Metrics leave their usual range.

Metrics models look across several measurements over time and mark the windows where behaviour changes.

  • Memory per podORDERS-API

    Grows after release

  • Container restartsK8S

    OOM restarts

  • Latency p95INGRESS

    Latency spikes

  • Requests per secondINGRESS

    Traffic unchanged

04 · Connect & inform

A lead your team can test.

Anomalies from logs and metrics are placed in order and combined with operational context into one finding.

Context added

  • Deployments
  • Cluster events
  • Release notes

Observations in order

  1. Rollout of orders-api v2.14.0 begins
  2. Memory per pod climbs steadily in the new pods
  3. Cache client reports an unusually large buffer
  4. First OOMKilled restart, then back-off
  5. Ingress timeouts and latency spikes follow

Illustrative operator finding

Likely lead to testThe orders-api v2.14.0 release: memory grows in new pods until they are restarted.

Why this lead?
Memory growth starts with the rollout and repeats after every restart, while request volume stays flat. The new cache client message appears only in this version, which points to the release rather than load or the cluster.
Suggested checks
  1. Compare memory profiles of v2.14.0 and the previous version.
  2. Review the release diff for cache client or buffer configuration changes.
  3. Decide whether to pause or roll back the release while the cause is confirmed.
Alternative to check
Node memory pressure could also cause restarts. Check whether pods of other services on the same nodes were affected.

Illustrative use case. Records, timings and values are invented to explain the intended workflow. Timing and relationships suggest a lead; they do not prove its cause.

Your operation

Which service would you start with?

A high-level description is enough: what you operate, the logs and metrics you collect, and where investigation gets difficult. We will discuss whether the approach fits before considering an evaluation.

Discuss your use case