Recover from refresh failures
Strent retries failed work automatically. Your part is the cause: a key Stripe rejects, a broken event destination, or a customer ID from the wrong account. The project Overview in Strent Admin lists each problem once, by cause, with how to fix it and how many customers or events it affects.
Problems on the Overview
Section titled “Problems on the Overview”| Problem | What to do |
|---|---|
| Stripe rejected the restricted key | Create a restricted key in Stripe and replace it in Configuration → Stripe. Replacing it refreshes every customer. |
| Stripe didn’t respond | Wait until Stripe answers, then use the problem’s action: Refresh from Stripe when one customer failed, Refresh all customers from Stripe otherwise. |
| Stripe has no customer with that ID | Your app saved an ID from another Stripe account or mode. Fix the ID in your app; refreshing reads nothing new. |
| Events from the other Stripe mode | An event destination sends the other mode’s events to this project. Point it at the project for that mode. |
| Strent couldn’t finish this | Strent was notified and is working on it. There is nothing for you to do. |
| Event destination or signing secret | Configuration → Stripe names the problem and its fix: a missing or disabled destination, the wrong payload, missing events, or a signing secret that doesn’t match. |
While a refresh of every customer runs, its progress replaces the refresh action. Each problem links to its evidence: the affected customers, the project refresh and the customers it could not read, or the newest event.
Customer state is not ready
Section titled “Customer state is not ready”When runtime calls return CUSTOMER_STATE_NOT_READY:
- Search the Stripe Customer ID in Customers in Strent Admin.
- If Strent hasn’t read it yet, use Refresh cus_… from Stripe in the search result. Strent first asks Stripe whether the customer exists in the project’s account and mode, and saves nothing if it doesn’t; an ID from another account or mode is the usual cause.
- Otherwise open the customer, read its Activity, and fix the cause the Overview reports, if any. Then use Refresh from Stripe on the customer and wait for Updated.
- Re-run the runtime read.
Use customers.retrieveBillingState for programmatic inspection. It returns 200 even when the customer has never been refreshed, with last_refreshed_at: null.
Suspected webhook gap
Section titled “Suspected webhook gap”Events lost while the event destination was broken leave customers stale without any failure Strent can see. Fix the destination in Stripe; Configuration → Stripe checks it each time you open it. Then use Refresh all customers from Stripe in Configuration → Stripe to catch the changes Strent missed. It reads every customer, can take several minutes on large accounts, and changes nothing in Stripe. A refresh reads current Stripe truth, so recovery never replays missed events.
Preserve the original failure
Section titled “Preserve the original failure”When recording or escalating an incident, keep the first actionable error, the Strent request or operation ID, the affected project and customer identifiers, and timestamps. Never include project API keys, Stripe keys, or webhook signing secrets.