Context
The indexer currently logs to console in an ad-hoc way. Once it's running on a schedule against a deployed environment, unstructured logs are hard to search, hard to aggregate, and hard to build alerting on top of. The planned retry and failure-alerting work will be significantly easier if there's structured output to key off first.
Scope
In scope: consistent structured logging (JSON or similar) across the indexer's run cycle — cycle start, per-adapter start/success/failure with duration and error detail, cycle summary. Same treatment for the cron trigger route.
Out of scope: shipping logs to an external service, and the alerting logic itself.
Acceptance criteria
Difficulty
Intermediate — needs familiarity with the codebase or methodology
Notes / open questions
Keep it dependency-light if possible. If a logging library is genuinely warranted, flag it in the PR with a reason rather than adding one by default.
Context
The indexer currently logs to console in an ad-hoc way. Once it's running on a schedule against a deployed environment, unstructured logs are hard to search, hard to aggregate, and hard to build alerting on top of. The planned retry and failure-alerting work will be significantly easier if there's structured output to key off first.
Scope
In scope: consistent structured logging (JSON or similar) across the indexer's run cycle — cycle start, per-adapter start/success/failure with duration and error detail, cycle summary. Same treatment for the cron trigger route.
Out of scope: shipping logs to an external service, and the alerting logic itself.
Acceptance criteria
Difficulty
Intermediate — needs familiarity with the codebase or methodology
Notes / open questions
Keep it dependency-light if possible. If a logging library is genuinely warranted, flag it in the PR with a reason rather than adding one by default.