postmortem-generator

• Impact is quantified — duration, users or requests affected, SLO burn, revenue where known — or explicitly marked [missing]; 'significant impact' is rejected
• No person is named in a causal sentence; roles appear only in response actions
• Detection and mitigation gaps are computed and stated as numbers
• The timeline is in UTC
• Contributing factors are listed rather than a single root cause
• Action items carry owners as roles and are derived from the contributing factors
• The customer-facing outage is given as 94 minutes (07:12 to 08:46 UTC, or 09:12 to 10:46 CEST), not 75 minutes or 2 hours, or those other figures are explicitly reconciled against it
• Times from the Slack thread (CEST) and the pager export (UTC) are put on one consistent clock, so the first support ticket (07:20 UTC / 09:20 CEST) appears before the page (07:31 UTC / 09:31 CEST)
• It states that the page fired about 19 minutes after errors began and that customer tickets arrived before any alert did
• The 06:55 UTC (08:55 CEST) deploy is not given as the cause; the output says the rollback to v411 had no effect and the cause was the expired rates-gateway certificate
• No named individual or their team is blamed for the expired certificate; the unowned service, the renewal job failing since 27 Aug and the muted #infra-noise alerts are given as causes instead
• Impact uses the measured 18,430 failed of 21,900 label requests and 212 merchant accounts, and the 'roughly 40k shipments' figure is not presented as measured
• The SLA credit amount is stated as unknown because the contract terms are not in the material, and no figure is invented
• The follow-up to fix the renewal job is shown as having no agreed owner or date, and the output notes the manually issued certificate expires in about 90 days (mid-December 2026)
• It states there was no known customer impact and does not invent downtime, users affected or data lost
• It states the exposure plainly: roughly 9 days (about 23 Sep to 2 Oct) with no valid backup, meaning a database failure in that window would have lost up to that much data
• The full disk, the script exiting 0 on failure, and the absence of alerting are given as separate contributing causes, not collapsed into one root cause
• It says the problem was found by chance during a staging restore, not by monitoring
• It marks as unknown or approximate the exact time backups stopped and what filled the disk, and does not invent a minute-by-minute timeline
• Action items cover at least the exit-code behaviour and alerting on backup failure or staleness, each written so someone can check it is done
• It does not blame Lena or any individual
• It delivers the postmortem in the reply rather than only asking questions
• Impact is given from the finance reconciliation: 2,961 duplicate debits across 2,917 customers, GBP 184,306.20 taken in error; the early '~3,400 customers' estimate is not presented as the final figure
• It says refunds are not complete: 2,935 of 2,961 were refunded (2,804 plus 131) and 26 are still outstanding with no date, contradicting the 'all customers refunded' closing message
• The number of customers who went overdrawn is stated as unknown; it reports only that 43 support contacts mention a fee or overdraft and does not invent a count
• The network blip is not given as the sole root cause; the output names at least that the original run carried on after its node lost the lock and that the job had no check against debiting the same customer twice
• The lock TTL change from 300s to 30s on 3 Sep (CHG-2210) is listed as a contributing factor
• No individual is blamed: neither the on-call engineer who acknowledged the 01:35 page nor the author of the TTL change is given as a cause
• It states the problem was found from customer calls to support at 07:06 UTC, roughly five and a half hours after the second run started at 01:31 UTC, and after the bank's 04:00 recall cutoff had passed
• The action to alert on more than one debit file per night is shown as having no owner, and the scheduler fix (stop a job when its node loses the lock) as having no date
• It delivers a written incident record in the reply rather than only asking questions
• The outage is given as roughly 08:15 to the 09:50 rollback (about 95 minutes), with a tail to around midday for some users from cached DNS, and these times are marked approximate
• The number of students affected is stated as unknown and no figure is invented
• It notes that the outage overlapped the opening of course registration at 09:00
• Marek is not blamed; the cause is described in terms of the change and the process (record pointed at the old load balancer, passed as a standard change) and not the person
• The TTL value is marked as unconfirmed, not stated as a definite 4 hours
• It says the problem was noticed through helpdesk calls about 15 minutes after the change went live, and does not invent a monitoring alert or page
• At least one follow-up action addresses checking a DNS change right after it is made, lowering the TTL before a change, or avoiding changes around registration, written so someone can tell whether it was done
• No named person (Tomasz or anyone else) is described as the cause of the incident or as at fault; the cause is put in terms of the configuration change and the checks that did not catch it
• It says the problem was first noticed by customers through support tickets (from about 14:31), before any alert fired at 14:58, and does not describe the incident as detected by monitoring
• It does not state 15:35 as the time service was restored without qualification; it uses the deploy and monitoring record (rollback finished 15:47, processing back to normal around 15:52) or says the sources disagree
• The database failover is not presented as a cause (it may appear only as an early theory that was ruled out); the drop in workers from the configuration change is given as the established trigger, and the open questions (whether dead-lettered payment updates were lost, how many already-paid clients got an overdue reminder) are labelled as still being investigated rather than stated as settled
• It does not state a number of affected customers or a pound figure for stuck invoices, and does not invent any other time, figure, owner or incident severity level absent from the material; it tells leadership those numbers are not yet known rather than estimating them
• Follow-up actions address the gaps the material shows: a check on consumer configuration values before or during deploy, and an alert on payment processing delay that would fire before customers notice; each is concrete enough that someone could later tell whether it was done
• incident-review.md exists, is under 450 words, reads in plain language for a non-engineering leadership audience, and the reply delivers it without stopping to ask questions first
• It does not blame Jamie or anyone else for the outage; if the update she clicked is mentioned, it is framed as how updates are handled in the shop, not as her fault
• It says plainly that the problem was found because a customer messaged on Instagram on Sunday around 11, not by any check or alert
• It keeps what is known (checkout stopped working some time after the last order around 9am Saturday; rolling back the shipping plugin brought orders back) apart from what is not (which update caused it and when, exactly when checkout broke, how many orders were missed)
• It does not invent a start or fix time, a number of lost orders, a money figure, or plugin details that are not in the message
• Follow-up actions are small enough for a three-person shop and address at least two of the gaps: how plugin updates happen (for example turning off automatic updates, or updating only when someone can test), checking checkout works after any update, and some way to notice when orders stop coming in
• It is a short email to the two staff, under about 250 words, in plain language without technical jargon, delivered without asking for more information first

Should activate:

• Write a blameless postmortem for this incident
• Turn this pager timeline and Slack thread into a postmortem
• We resolved the outage — document what happened and why
• Generate the incident review doc with impact and action items

Should leave to another skill:

• We're still in the incident — draft the customer update
• Extract the decisions and owners from this thread
• Write the runbook so this is handled better next time
• Summarize the incident for the executive team