Skip to content

0012: Dynamic Log Severity

  • Status: Proposed
  • Date: 2026-03-21
  • Owners: @cagkan, @osmank, @enver
  • Context: Osman Celik proposed improving the logging infrastructure with dynamic, flag-based logging that can be toggled on/off without restarting services. After discussion with backend lead Enver Gokmen, the current state was clarified: nlog is already in use across backend services with environment-variable-based log level configuration. Self-hosted deployments default to info level; the API gateway defaults to warning. Developers already instrument code with appropriate log statements at various severity levels.

The core question is whether to invest in a runtime-configurable logging system or leverage the existing infrastructure more effectively.

Decision

Adopt a phased approach:

  • Phase 0 (immediate): Document the existing log level configuration mechanism in the self-hosted documentation. Self-hosted customers can already change log severity via environment variables and restart — this is undocumented today.
  • Phase 1 (mid-term): Add a log level toggle to the Appcircle Admin panel, allowing log severity to be changed at runtime without a restart. Applies to both self-hosted and cloud deployments — in cloud, this enables the operations team to increase verbosity for diagnostics on demand.
  • Phase 2 (future consideration): Enable per-organization dynamic log level control for cloud tenants, allowing granular verbosity changes scoped to a single organization without affecting others.

Phase 0 starts immediately. Phase 1 is backlogged for prioritization. Phase 2 is deferred — scope and feasibility to be evaluated separately when the need arises.

Options Considered

  • Option A: Do nothing — The current setup works but is undocumented. Customers don't know they can change log levels. Low cost, low value.
  • Option B: Document existing capability (Phase 0 only) — Minimal effort, unblocks self-hosted customers today. Does not address the restart requirement.
  • Option C: Full dynamic logging system (all phases at once) — High engineering cost, requires runtime config propagation, admin UI work, and multi-tenant isolation for cloud. Enver's assessment: costly relative to current demand.
  • Option D: Phased approach (chosen) — Delivers immediate value through documentation, defers engineering investment until demand justifies it. Each phase is independently valuable and does not block the next.

Consequences

  • Positive:
  • Self-hosted customers gain immediate visibility into log level configuration
  • Engineering effort is deferred until prioritized, avoiding premature investment
  • The phased model preserves the option to build runtime controls when needed
  • Negative:
  • Phase 0 still requires a restart to change log levels — not ideal for production debugging
  • Phase 1 and 2 remain unfunded — risk of indefinite deferral
  • Follow-ups:
  • Create documentation PR for self-hosted log level configuration (Phase 0)
  • Create backlog issues for Phase 1 and Phase 2
  • Related issues/PRs: to be added
  • Supersedes / superseded by: —