# Close: Major incident: Application impairment

**Summary:** Close reported a major Application UI outage in which parts of the application failed to load. The incident started at 2026-09-29 17:48 UTC and was resolved at 2026-09-29 18:15 UTC, lasting 26 min. Close said the issue was identified and reverted. _(machine-written, sol)_
- Kind: Major incident · Label: outage (model (Jev))
- Changed: 2026-09-29 17:48 UTC · Detected: 2026-10-17 18:22 UTC
- [Source: https://stspg.io/4vzsppvqmv4k](https://stspg.io/4vzsppvqmv4k)
- [Company: Close](https://rewindex.com/company/close.md)
- Versions: before (none: first archived) → after incident\_version:128/7g19k4myv9tq@1939e71df677
- Change 1 of 1 for this incident

## What changed

**1. Added: Title**

```diff
+ Application impairment
```

**2. Added: Impact**

```diff
+ major
```

**3. Added: Status**

```diff
+ postmortem
```

**4. Added: Start time**

```diff
+ 2026-09-29 17:48 UTC
```

**5. Added: Resolved time**

```diff
+ 2026-09-29 18:15 UTC
```

**6. Added: Affected components**

```diff
+ Application UI
```

**7. Added: Update** (investigating) · 2026-09-29 17:48 UTC

```diff
+ We are currently investigating issues with parts of the Close application not loading.
```

**8. Added: Update** (monitoring) · 2026-09-29 18:11 UTC

```diff
+ The issue was identified and reverted. We continue to monitor the application to ensure everything is back to normal.
```

**9. Added: Update** (resolved) · 2026-09-29 18:15 UTC

```diff
+ This incident has been resolved.
```

**10. Added: Update** (postmortem) · 2026-10-05 17:25 UTC

```diff
+ Close sincerely apologizes for the interruption of our service. We take the stability of our platform very seriously. Below is an explanation of what happened and how we will prevent another such interruption from occurring. ## Impact Close systems were unavailable for 30 minutes from Sep 29, 17:40 UTC to Sep 29, 18:10 UTC. ## Root Cause and Resolution During deployment of a new application version, we ran a multi-phased migration that added a permission to user roles and assigned it to existing custom roles.  The timing of the phased migration wasn’t fully thought out; many application servers were still running the previous version which didn’t recognize the new permission in the database. As a result, error rates increased. We restored service by removing the permission from existing roles. To prevent similar incidents, we’re updating our testing and deployment pipeline to identify migrations that require a phased rollout. ## Timeline * 17:40 UTC - Migration was run and PR was merged. * 17:41 UTC - Engineering team alerted of API failures and application unresponsiveness * 17:43 UTC - Engineering team begins incident response, status page updated * 17:44 UTC - Potential root cause identified \(backfill migration was run before code finished deploying\).  * 17:44 UTC - We thought we could fall forward, but realized that was going to take longer so we then decided to revert the migration. This added to the outage time. * 18:10 UTC - Engineering team runs a script to drop the new permission from existing custom roles * 18:10 UTC - Application loading again, error rates dropped. Customer impact ends.
```

## History of this incident

| When (UTC) | Change | Label |
| --- | --- | --- |
| 2026-09-29 17:48 UTC | Major incident: Application impairment (this change) | outage |

All Close changes: [timeline](https://rewindex.com/company/close/changes.md)
_Diff excerpts are shown on normalized text: dates, counters and tokens appear as ‹date›, ‹count›, ‹tok›; noise-only edits are hidden. Rewindex shows the changed passages, not a copy of the page._


---
Canonical: https://rewindex.com/change/i26728feca6f3c0 · Markdown: https://rewindex.com/change/i26728feca6f3c0.md · JSON: https://rewindex.com/api/v1/changes/i26728feca6f3c0 · Generated 2026-10-18T02:29:18.860Z