GitHub's cleanup bot revokes access when nobody answers, but never deletes. Use that pattern for CRM cleanup

GitHub published how it automates access reviews and stale repo cleanup. The design rules fit any CRM cleanup job.

What happened

GitHub described Evergreen, a GitHub App it uses in a shared organization where staff work with customers and partners. It runs two workflows: a quarterly review of each repo's outside collaborators, and detection and archival of repos with no recent human activity.

The rules are explicit. Fail secure: if nobody answers an access review, access is revoked. Never destroy: Evergreen never deletes a repo, archived repos are recoverable, and every access change is written into the repo's tracking issue so it can be reverted. Reviews open two weeks before cleanup, with a reminder before the deadline and an opt out flag.

Owners respond by ticking boxes in an issue and closing it. If someone without authority closes it, the app reopens it. Each repo's state is a JSON file in git, so the commit history is the audit trail. If any removal fails, the review stays open and retries next run.

Before going live, the team ran a dry run mode that logged every write without making it, sent structured logs to Splunk, and paced its calls. GitHub's docs say content-generating requests are generally limited to 80 per minute and 500 per hour.

My take

Swap repos for CRM records and this is the cleanup most teams need and avoid: stale deals, users who left, duplicate contacts, old pipelines.

The reason teams avoid it is fear of deleting the wrong thing. Evergreen answers that fear with design:

• Archive or tag, never delete, in the first version.
• Ask the owner first, with a clear deadline and a reminder.
• Make the default safe. For access, the safe default is removal; for records, it is usually "move to an archive stage".
• Write every change somewhere a person can read and undo it.
• Ship a dry run that reports what it would change, and read it before switching it on.
• Pace API calls. CRM APIs have limits too, and a cleanup that trips them fails halfway.

Partial failure handling is the part most homemade scripts skip. Do not mark a job done until every step succeeded.