# Run events go to a file per Run, not to SQL

Every Run writes its events (eCW Login Attempt steps, Run Errors, Claim
Errors, Warnings, each with its time) to `Logs\events_<run>.jsonl`, and the
Portal's Runs page reads those files — while the Charge Summary rows, Portal
Users and Sign-in history live in SQL Server (`Charge_Validation`). We chose
files because the events matter most exactly when things go wrong: during
the eCW login (before the database is touched at all), when SQL Server is
down, and when a Run is killed or the browser crashes — a line flushed to a
file survives all of those, the same way `Logs\run_<ts>.log` already does.

## Considered Options

- **SQL table (`CV_RunEvent`)**: easier filtering across months, but a Run
  with no database would lose its own failure record, and the bot's results
  write is deliberately never fatal — events would inherit that "maybe".
- **Parse the existing run logs**: no bot change, but the log lines carry
  no time, so login durations and error times could not be shown.

## Consequences

- The Runs page reads one small file per Run; if that ever gets slow, load
  the files into SQL as a copy, keeping the files as the source.
- Portal Users and Sign-ins are in SQL because the Portal already needs SQL
  for its results; a Portal with no database shows nothing either way.