The Synaptore approach

From an unusual signal to a useful lead.

Synaptore is operational investigation software in development. It starts with logs and metrics your systems already produce, with the aim of turning unusual behaviour into a finding your operations team can examine and act on.

One service. Three stages.

A checkout starts slowing down.

Several services show symptoms. Which change is worth investigating first, and what evidence would make that lead useful?

Illustrative walkthrough. All records, timings and outputs below are invented to explain the intended workflow, not a customer incident or a running product. For this example, the service relationship is supplied: checkout calls an API, and the API calls a database.

Reference · usual behaviour

Queries complete.

Query starts → completes → connection released

A representative history provides a reference for this service’s event patterns.

Observation · changed behaviour

Timeouts recur.

Query starts → times out → retry → query timeout

The repeated pattern is a candidate for investigation. Its cause is still unknown.

Context · order matters

Follow the observations.

The first observed change and the supplied service relationship help form a lead. They do not establish the cause.

First · database: Repeated timeout records replace the usual completion pattern.
Then · API: Retries of database calls appear.
Later · checkout: Response times rise.

Detect.
Recognise a departure from usual behaviour.
Compare the sequence of database events with a learned reference for that service. The changed pattern becomes a candidate for investigation, with its source records retained for review.
Output: an unusual pattern, with the service and observation window attached.
An anomaly is a clue. It may reflect a fault, a planned change or normal variation.
Connect.
Add context from related observations.
The database change appears before the API retries, which refer to database calls. Checkout depends on that API. Together, these observations support testing a database-related explanation first.
Output: database change → API retries → slower checkout, presented as a possible relationship.
Events occurring together do not establish which one caused the others.
Inform.
Give the operator a finding they can examine.
Bring the source observations, reason for the lead, an alternative explanation and a useful next check into one finding. The operator decides whether the evidence holds.
Output: an investigation lead with the reasoning visible.
People verify the explanation and choose any operational action.

Foundation and direction

The foundation. The next layer.

The anomaly-detection foundation and the complete investigation workflow have different maturity levels. Here is the distinction.

Technical foundation

Models for logs and metrics

Our work includes log models that turn messages into structured representations and learn patterns across sequences of events. Separate metrics models examine patterns across numerical observations over time.

New observations are compared with the learned reference to identify departures. The practical question is whether those departures help an operator investigate. Flagging a change is only the starting point.

Development direction

Connected operational context

We’re developing the integrated Detect → Connect → Inform workflow: bringing unusual patterns together with relevant service context and an explanation people can inspect.

The walkthrough describes that intended experience. Deployment, integration and performance of the complete engine still need to be established for each use case.

A useful starting point

Start with one service and a clear question.

A technical discovery conversation can establish whether the problem fits our approach and what a meaningful evaluation would require.

Discuss your service

Which service and signals?

Identify the critical service, the logs and metrics available, their quality, and the context needed to interpret them.

What is the comparison?

Use the current monitoring process and suitable simple baselines. Examine missed events, alert burden and whether a lead helps an operator investigate.

What would adoption require?

Discuss data access, deployment constraints, integration effort and ownership of the response. These depend on the use case and must be established together.