See what it does

Each recording is summarized twice: once from the sound alone, the way transcript tools work, and once by Screen Gist, listening and watching. Highlighted details were only ever on screen.

A tech lead and a senior engineer on a live incident call. The engineer shares a dashboard, a terminal on the broken server, the fix and the incident doc. They point at the screen ("that panel", "the line at the bottom") instead of reading numbers out.

Listening only is what a transcript-based summary gets. Listening and watching is Screen Gist. Highlighted: only on screen, never said.

Listening only

0 of 11 on-screen details

A morning spike in 502 errors on the API was traced to two servers whose disks filled up because debug logging had accidentally reached the production config. Alex truncated the logs to restore service, a config fix was shipped, and follow-ups were assigned, with the status page to say it was a resolved configuration issue with no data lost.

  • 0:02
    Incident overview — Speaker 1 needs a status page update in ten minutes, and Alex shares the API dashboard showing errors climbing after nine.
  • 0:29
    Two affected hosts — Only two of six servers show high load, and both filled their disks since Monday.
  • 0:58
    Why disks cause 502s — Nginx can't buffer large responses to disk and returns 502s, so large requests fail while small ones succeed.
  • 1:15
    Debug logging fills the disk — The application log is huge because debug logging writes full payloads, and weekly rotation with no size limit didn't help.
  • 2:11
    Root cause in the release — A staging debug log-level change for a timeout bug rode along into Monday's production config and was missed in review.
  • 2:42
    The fix and recovery — The log level goes back to info, rotation becomes daily with compression and a size cap, and the current logs are truncated, which brings errors down.
  • 3:41
    Timeline and impact — The incident doc covers the timeline from the first alert after nine to full recovery just after half past, with large responses like audit history and exports affected and checkout up.
  • 4:11
    Follow-ups and status — Four follow-ups are listed (config fix, disk alert, CI check, postmortem draft by Thursday), Speaker 1 takes the alert, and the status page will say it was a resolved configuration issue with no data lost.

Screen Gist, listening and watching

9 of 11 on-screen details

An incident bridge for INC-2307 covers 502 errors on api.bramblecart.com, caused by full disks on two of six API hosts after debug logging reached production with Monday's release. Alex Rivera truncated the logs to restore service, shipped a config and log rotation fix, and agreed follow-ups and a status page message with Marcus Hale.

  • 0:00
    Incident overview — Alex shares the dashboard showing a 5xx spike on api.bramblecart.com, and Marcus needs a status page update within ten minutes.
  • 0:29
    Two hosts failing — Only api-prod-2 and api-prod-5 are failing, because their disks filled around 09:12 and Nginx returns 502 for large responses it can't buffer.
  • 1:15
    Root cause in the logs — On api-prod-5, a 94G checkout-api app.log fills /var because debug logging writes full payloads, and logrotate was weekly with no size cap.
  • 2:11
    How debug got enabled — PR #2214 shows a staging debug setting rode into the production config with Monday's release (v2.31.0) and was missed in review.
  • 2:42
    The fix — The PR sets the log level back to info and moves rotation to daily with compression and a 2G size cap.
  • 3:02
    Immediate recovery — Alex truncates the current log on both hosts after copying off the last hour, and errors and disk usage drop.
  • 3:41
    Timeline and impact — The incident doc lists 1,860 failed requests over 19 minutes (09:12 to 09:31), mostly large responses, with checkout staying up and no data lost.
  • 4:11
    Follow-ups and status — Follow-ups are the config fix, a disk alert (Marcus takes it), a CI check for debug logging in production, and a postmortem draft by Thursday; the status page will say it was a configuration issue on two servers, resolved, with no data lost.

Detail by detail

Things shown on screen but never said out loud. Did each summary get them?

Shown on screenListening onlyListening and watching
Incident number (INC-2307)NoYes
Which servers failed (api-prod-2, api-prod-5)NoYes
When the disks filled (09:12)NoYes
Size of the runaway log (94G)NoYes
The release that turned on debug logging (v2.31.0)NoYes
The fix's pull request (#2214)NoYes
The new log size cap (2G)NoYes
Failed requests (1,860)NoYes
How long it lasted (19 minutes)NoYes
Peak error rate (38%)NoNo
Disk alert threshold (80%)NoNo

A made-up call recorded for this page, with synthetic voices; the company, people and numbers are invented. Both summaries are Screen Gist's own output on the same recording, unedited apart from formatting.