Application impairment

What to do

• Check whether you use Close Application UI. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 26m it lasted.

  Anything that failed between 2026-09-29 17:48 UTC and 2026-09-29 18:15 UTC may need a replay.

• Subscribe to Close's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=close works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Root cause

## Root Cause and Resolution

Updates from Close 4

1. investigatingSep 29, 2026, 5:48 PM UTC

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

   provider

2. monitoringSep 29, 2026, 6:11 PM UTC

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

   provider

3. resolvedSep 29, 2026, 6:15 PM UTC

   This incident has been resolved.

   provider

4. postmortemOct 5, 2026, 5:25 PM UTC

   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.

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.