# SRE incident communication page sources Reviewed on 2026-09-15, moved to this page on 2026-09-21. The run below was recorded for the Chat task page and is unchanged; only the page it backs changed, because `/chat` went back to being a general capability page and this incident-communications scenario got a page of its own. Every input is a public post-incident report from Wikimedia's Wikitech wiki, pinned to one page revision. The page shows short excerpts of these reports beside the status update the model wrote from them. ## License and attribution Wikitech text is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license (). The authors are the contributors listed in each page's revision history, linked below. Wikimedia does not endorse this page or Superlinked. Changes: each pinned revision was converted from wikitext to plain text by a deterministic script (markup, images, tables and the closing scorecard checklist removed; the incident scorecard kept as labelled lines). The page title is kept at the top of each report because some scorecards give times without a date. The excerpts shown on the page are shortened from that text. Those excerpts are shared under the same CC BY-SA 4.0 license. ## Incident reports ### 2025-03-31 sessionstore unavailability - Revision: - History and authors: - SHA-256 of the pinned wikitext: `ef9de3f2aeb8f4e3ff31c76c2bafdf65f43e7dd49209b45198a76f46f0231fb5` ### 2025-04-30 Gerrit data corruption - Revision: - History and authors: - SHA-256 of the pinned wikitext: `5dc0138871d65621375d12a4bc79687e46f08e7038071a6acacece65f88aca7c` ### 2025-05-07 cloud-vps security groups deleted - Revision: - History and authors: - SHA-256 of the pinned wikitext: `280971efc01d0574811eee4311e7a84651d110744c8569bd4c33e2f3c854a167` ### 2025-03-29 Upload cache unavailability - Revision: - History and authors: - SHA-256 of the pinned wikitext: `8fc8d979adec0929d6771f4821421c4060d01e93a9197159fc358d6d9b5e292f` ### 2024-12-03 Port saturation from cached Varnish HEAD-GET upgrades - Revision: - History and authors: - SHA-256 of the pinned wikitext: `2e4359735e0611cc48067997079f47ac639431c26047cbe9e87359b5e01dc0c5` ### 2025-11-05 WMCS toolsdb primary out of space - Revision: - History and authors: - SHA-256 of the pinned wikitext: `91cf7862333f21248750db6a9ba3ca42de9557f34ff2de09ac0471cdbb66041b` ### 2025-07-17 Cite + VisualEditor list-defined reference disappearances - Revision: - History and authors: - SHA-256 of the pinned wikitext: `2ae3d698b456ca2382e6ca236b0d33a3c83b95679f40a93c85735d9d2d793471` ### 2024-07-21 s4 and x1 write overload - Revision: - History and authors: - SHA-256 of the pinned wikitext: `72a0f1d18caad1b2baef8bd3800e08c8a91c3b3b28d5863641912ce41886c21c` ### 2025-03-12 ExternalStorage Database Cluster Overload - Revision: - History and authors: - SHA-256 of the pinned wikitext: `9e1e67303fa3e5f5a16d3afe912706cd5c31e9719c7f1540824735635c269601` ### 2025-11-11 WMCS toolsdb primary down - Revision: - History and authors: - SHA-256 of the pinned wikitext: `cd52721c1e9b86c6c985d4c4b6b70d332a23e72dfb34223afdf0860e3e7e8a1e` ### 2025-05-09 Missing autocomplete indices - Revision: - History and authors: - SHA-256 of the pinned wikitext: `bbed05f46e6bf949456933ba7385f2f3003e0f3897621a7960dcb38aa1725968` ### 2024-11-25 WMCS proxy nginx failure - Revision: - History and authors: - SHA-256 of the pinned wikitext: `3e98707bf55ada0310d38ea1a144b58e6c563c4a8218b3429670fc58e85a75ea` ## Acceptance checks The checks were fixed before the evidence run and are scored by the runner, not by hand. A status update passes a check only when: - Format: it is exactly four lines labelled Status, Impact, Window and Cause, with `Status: Resolved` and a `YYYY-MM-DD HH:MM to YYYY-MM-DD HH:MM UTC` window. - Window: the start and end match times the report itself states for the incident. - Length: Impact and Cause are each 25 words or fewer. - No internal identifiers: it names no hostname, Phabricator task or staff member from the report. A request that returns an HTTP error or no text scores zero checks. The evaluation records a `checks_sha256` digest covering everything that decides a score: the pinned inputs, the prompt, the word limit, the leak patterns and the source of the scoring functions. Changing any rule changes the digest, and the export refuses to run against an evaluation scored by older rules. Widening that digest to cover the evaluator's own rules moved no score: all 12 reports still pass all four checks. The checks do not score factual accuracy. A status update can pass all four and still describe the cause loosely. For the 2025-03-29 upload cache report, the model wrote that downloads "overloaded the cache infrastructure", while the report names the Swift media store as the overloaded service. ## What the page displays All 12 reports are scored, counted in the totals and held in the page data. The page draws 4 of them: the hero report and three proof cards. The grid was cut from six cards to three in September 2026 so the section reads in one pass; the cut removed no report, answer or score. The other 8 reports are scored and counted, and no card draws them. All eight pass every check, so the cut leaves out no failure. No recorded report fails a check at all, which the site's unit tests assert against `evaluation.json` rather than against the page data, so a selection here cannot turn a failure into a clean sweep. The three cards carry one trap each: | Card | Recorded slug | The trap | | --- | --- | --- | | ExternalStorage cluster overload | `externalstorage-overload` | Two outage windows in the scorecard, and fifteen identifiers to leave out | | WMCS proxy nginx failure | `wmcs-proxy-nginx` | A scorecard giving clock times and no date | | Varnish port saturation | `varnish-port-saturation` | A window six days wide, under an impact line reading "Not particularly public" | The line under the grid states the same split on the page itself, and site CI compares that sentence with the built page. ## Recorded model run - Model: `Qwen/Qwen3.8-27B-FP8` (Apache-2.0), - Served execution revision (`x-sie-model-revision` response header): `8bd714204e67a1c6c81f84b0dc486b6a6e96e943c42ff488f6b3cbf936e07955` - Endpoint: `POST https://api.superlinked.com/v1/chat/completions` - Request: `model`, a system message with the instruction, a user message with the report title and report, and `max_completion_tokens: 256`. No sampling fields were sent. - Run date: 2026-09-15. One attempt per report, no retries. - Result: HTTP 200 on 12 of 12 reports. All 12 answers pass all four checks. - Latency: 5.2 to 7.5 seconds per report, median 5.7 seconds, measured as client wall clock from sending the request to receiving the full response. - Usage: 667 to 3,298 prompt tokens and 76 to 101 completion tokens per report. - Playground example: one more call on a brief excerpt of the sessionstore report: its title, the Task, Start, End and Impact lines, and the first Summary paragraph. It passed all four checks and left the ticket number T390513 out of the update. It is not counted in the 12. An earlier playground call on a longer excerpt stays in the test fixtures as history and is not shown. The website does not serve the raw run files. They live in `apps/site/tests/fixtures/reference/sre/`, and site CI compares the page data with them: `calls.json` holds one entry per recorded call with its request body, response, status, headers, latency and model revision, and `sources/` holds the twelve licensed incident reports, each pinned by revision id, URL, licence and digest in `sources/index.json`. `manifest.json`, `evaluation.json` and `run.py` sit beside them. `calls.json` uses the schema `superlinked/sie` uses for `examples/document-to-markdown/runs/*/calls.json`. Its 19 entries carry a `role`: 14 are the page's `/v1/chat/completions` evidence, 4 are diagnostics recorded to compare `/v1/generate` with `/v1/chat/completions` for sie-internal#4370 and are never displayed, and 1 is a recorded `/v1/generate` failure kept on the record. `manifest.json` separately lists two 502 attempts whose bodies were never stored, so they have a digest there and no entry here. Each entry carries `entry_sha256`, the RFC 8785 canonical digest of the entry, which CI recomputes; the `recorded_sha256` values are the digests the manifest already carried, over the parsed request and response rather than over any file, which is why combining the files did not move them. CI does not check that the twelve reports are representative of incident reports generally. ## What the recorded run covers, and what it does not The run covers one stage: writing the public update from the internal report. Every model output this page displays, and every number on it, comes from that run. The case study's tool grid names four further SIE tasks an incident communications agent composes around it, and those four were not run for this page. They are named as the task a stage calls, never as a recorded result. The four checks are mechanical. An update whose Cause line confidently misdescribes the outage passes all four, as long as it is well formed, short, inside the stated window and free of identifiers. Nobody checked the twelve summaries against the reports for accuracy. The leak check knows four regular expressions plus the names each report itself lists, so an internal identifier in a shape those patterns miss would pass. Twelve reports on one day, from one organisation, in one house format, is a recording and not a measured pass rate. ## Runnable example [`examples/chat`](https://github.com/superlinked/sie/tree/c303dfc7f7a0c0000bc6338ca20fcf40e6ee2678/examples/chat) in `superlinked/sie` downloads the recorded calls from the public Hugging Face dataset `superlinked/sie-task-evidence` at a pinned revision and rescores them with no API key and no inference spend. The link pins a commit, so it still shows this example now that superlinked/sie#317 has renamed the directory to `examples/incident-status-updates`: at the pinned commit that path does not exist yet and this run lives at `examples/chat`.