Thomas Nelson

One pattern I keep seeing is that logging starts out useful, then gradually becomes inconsistent, noisy, expensive, and harder to trust. Field names drift, context goes missing, dashboards get polluted, and sometimes sensitive data ends up in places it never should have reached.

The deeper problem seems to be that most teams try to fix logging after the data has already entered downstream tools. By then, the cost, risk, and cleanup burden are already there.

I m curious how other teams handle this. What breaks first in practice: naming consistency, missing required context, sensitive fields in logs, alert noise, or ingestion cost? I m building in this area and want to learn where current approaches still fall short.

I m building CerbiSuite: governed logging for teams that need structured logs without accidental PII/PHI leaks or schema chaos.

This week I shipped the first end-to-end scoring pipeline: CerbiStream + logger plugins emit a lightweight scoring event (violations, required field misses, redaction hits no raw log bodies), and a new Scoring API ingests it and writes to Postgres with idempotent semantics. The goal is to make governance measurable over time (drift, coverage, risk), not a doc people forget.

In parallel I ve been doing a ton of voice-of-customer work cost sprawl, inconsistent fields across services, compliance reviews where nobody can prove what s logged, and dashboards that break whenever one team just adds a property.

Targeting a January release, aligned with Microsoft as we finalize Marketplace/ISV readiness.

Hey everyone

I m Thomas, a principal architect-turned-founder working mostly in cloud-native backend systems (.NET, Azure, distributed apps, all the usual suspects).

Over the last few years I kept running into the same mess at every company:

• Logs scattered across tools

• Observability bills creeping into this can t be right territory

• Zero governance on what people log (PII everywhere, no standards, no consistency)