Which records help a company explain how a rollback exception was handled?
The records that show the initial problem, the authorized action and the checked result. A partial rollback is an exception worth documenting because the incident ticket often says "rolled back" while the flag history shows that only some customers were changed.
Ordinary rollbacks are easy to describe: a release breaks, the flag goes off, the errors stop. The exceptions are the cases where the responder chose something narrower or stranger than "everything off": one region, one segment, one percentage step back, or a rollback that was reverted when it made things worse. Those choices are judgment calls, and the history only explains them when the flag change and the incident record can be read side by side.
Worked example: a rollback that changes only one customer cohort
Illustrative. A fictional 320-person B2B software company serves customers from three hosting regions. It is releasing a new scheduling engine behind a flag, on for 20% of accounts in every region. All names and times are invented.
- 09:12, incident opened. Monitoring raises an alert for elevated errors in the EU region. The on-call engineer is paged.
- 09:20, acknowledged. The responder posts in the incident channel: errors are limited to EU accounts with the new engine on.
- 09:31, flag change. The responder edits one targeting rule so the EU region segment is served the old engine. The US and AU regions stay at 20%. The incident note reads "rolled back new engine".
- 09:45, recovery check. The EU error rate is back at its baseline; US and AU show no change. The responder records the check in the incident.
- 10:05, resolved. The incident is closed with the incident log covering 09:12 to 10:05.
- Day 3, postmortem. The review records the cause, the decision to roll back one cohort rather than all, and a follow-up to fix the engine before re-enabling the EU region.
The note at step 3 says "rolled back"; the flag history says one rule for one segment. Only the two records together show what was actually decided: a scoped rollback that kept the release running for most customers. That is the kind of judgment, with its evidence and outcome, that makes incident histories useful for training and evaluating agents that do operational software work.
Targeting rules make this kind of decision possible. LaunchDarkly's documentation describes a targeting rule as a set of conditions plus a rollout that serves one variation or a percentage of contexts, and rules can match contexts by segment. A rollback that edits one rule for one segment is ordinary platform behavior; the exception is that the incident record does not say so.
The record map: what each record proves
Each record answers a different question about the exception. If one is missing, the case still exists but loses part of its meaning.
| Record | Typical system | Fields that matter | What it proves |
|---|---|---|---|
| Flag change | Flag platform change history | Flag key, environment, rule edited, member, timestamp, before and after values | Exactly which customers were changed, by whom |
| Incident timeline | Incident platform | Status timestamps, responder actions, notifications | Why the change was made and how fast |
| Incident channel messages | Team chat | Responder notes, hypotheses, approvals | The reasoning between alert and action |
| Recovery check | Monitoring, noted in the incident | Metric, cohort, baseline, time of check | Whether the scoped rollback worked |
| Postmortem | Document store or wiki | Impact, actions taken, root cause, follow-ups | The accepted explanation and next step |
The vendor documentation supports why the first two rows are usually the strongest. LaunchDarkly's change history records changes to flags per environment, showing the member, resource, environment, date and a diff, and can be filtered by project, environment and action. PagerDuty gives each incident a timeline with timestamps for each status, the actions taken and the notifications sent, and its REST API can list log entries for an incident. The postmortem closes the loop: Google SRE authors describe a postmortem as a written record of an incident covering its impact, the actions taken to mitigate or resolve it, the root causes and the follow-up actions.
PagerDutyWhat separates a useful rollback history from a thin one
A partner cannot judge quality from records, and should not try. These are questions the engineering director can answer at metadata level:
- Join keys. Do incident records cite the flag key, or can the two be joined by environment and time?
- Scope recorded. Do notes say which cohort, region or percentage changed, or only "rolled back"?
- Checks written down. Is the recovery check recorded in the incident, or only seen on a dashboard at the time?
- Postmortem habit. Roughly what share of rollback incidents got a written review, and over which years?
- Volume and span. About how many rollback incidents exist, and how far back does the flag change history go?
The exception workflows guide uses the same problem, action and result test for purchasing, and the incident and on-call records checklist covers incident data more broadly.
Does the company qualify, and what stays unknown?
The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records, and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English.
What stays unknown until SourceX reviews it: whether customer-identifying details in incident messages can be removed, which records the company has rights to license, SourceX's current data needs for this record type, and any offer. The data rights explainer covers the rights review in general terms. Partners sign the Channel Partner Agreement before submitting introductions.
Go deeper on feature flag incident rollbacks
- Reconstructing rollbacks across systems: a system map of the keys and timestamps that join flag history, incident timelines and chat.
- Who can license feature flag rollback records: a short answer on which engineering and executive roles to introduce.
- Preserving rollback history before a flag platform replacement: an inventory checklist for the months before a migration.
- Feature flag rollback referral brief template: a fill-in template for the one-page introduction.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If a client's rollback incidents can still be traced from flag change to recovery check, register as a partner, check the company against who qualifies, and read the terms and reward rules before you send the brief.