Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

observability: the structured logger exists but nothing uses it (237 console.* calls, 0 importers)

Open
  • Is something wrong?
#197 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 4 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Quiet
Tech stack
typescript
Domain
observability

Research direction

Start with packages/outpost/shared/src/monitoring/logger.ts, its test file, and the export in monitoring/index.ts to understand the existing capability. Then inspect the entry points under apps/worker, the three bots, apps/github-app, and apps/web, beginning with the worker job handlers. Done means relevant console.* calls are adopted incrementally with service and job metadata, and AlertManager's wiring or removal is decided.

Written by the indexing model from the issue text.

Description

area: infrastructure roadmap roadmap: next

Corrected 2026-08-17. This issue originally said no structured logging existed and one should be built. That was wrong — I checked for pino/winston/bunyan dependencies, found none, and concluded there was no logger. There is one.

What actually exists

packages/outpost/shared/src/monitoring/logger.ts — a structured JSON logger shipped in PR #21 (Phase 4D, "Deploy + Monitoring"). One JSON object per line, with timestamp, level, service, message, plus metadata. Five levels, level filtering, an injectable writer for tests. It has its own test file.

It is exported from packages/outpost/shared/src/monitoring/index.ts.

The actual problem

Nothing imports it. Zero call sites outside the module and its own tests. Meanwhile there are 237 console.* calls in non-test source across apps/ and packages/.

So the work is not "build a logger" — it is "adopt the logger that was built." That is a much smaller and much better-defined task, and it is the reason production logs are still unstructured despite Phase 4D being marked complete.

Related: AlertManager has the same shape

packages/outpost/shared/src/monitoring/alerts.ts exports AlertManager and createAlertManager. Referenced only by its own module, the barrel export, and its test file — never instantiated anywhere in a running service. Noted as dead code in the Build Plan's own confidence-design section ("it's dead code today, never instantiated outside its own test file"). Tracked alongside the Sentry stub in #196.

Fix

  1. Bind a logger per service at each entry point (apps/worker, the three bots, apps/github-app, apps/web).
  2. Replace console.* incrementally, starting with the worker and the job handlers, where the structure actually buys correlation — jobId, ticketId, job type.
  3. Decide whether AlertManager gets wired to a real sink or deleted. A monitoring module that no service uses is worse than none, because it reads as covered.

The general lesson worth recording: Phase 4D shipped the capability and never the adoption, and every status doc since has counted it as done.

Dominant language
TypeScript
Stars
10
Forks
4
Avg merge
4d 2h
Merged PRs (30d)
7

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CopilotKit/outpost

All issues in CopilotKit/outpost

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.