Autumn’s SDKs include a fail-open mechanism that prevents your application from going down if Autumn is temporarily unreachable. When enabled, critical SDK methods return safe default responses instead of throwing errors.
Why fail-open?
As a billing engine, Autumn sits in the critical path of your application. If your app calls check() to gate access to a feature, and Autumn is unreachable, that call would throw an error — effectively blocking your users from accessing your product.
Fail-open ensures your users are never blocked by an Autumn outage. Usage events may be lost during the outage, but your customers stay unaffected.
Behavior
Fail-open is enabled by default. When Autumn is unreachable (network errors, timeouts, or server errors returning 5XX status codes), the SDK returns safe defaults:
When fail-open triggers, the SDK logs a prominent error to your console so you’re immediately aware of the issue.
When fail-open triggers
Fail-open activates when the SDK encounters:
- Server errors — Autumn returns a 5XX status code (500, 502, 503, etc.)
- Network failures — DNS resolution failure, connection refused, connection reset
- Timeouts — The request to Autumn times out
Fail-open does not activate for client errors (4XX). If you receive a 400 (bad request), 401 (unauthorized), or 404 (not found), those errors propagate normally since they indicate a problem with your integration, not an Autumn outage.
Configuration
Disabling fail-open
If you prefer strict error handling and want all Autumn errors to propagate:
Detecting fail-open responses
When check() fails open, the response will have allowed: true with empty values:
When customers.getOrCreate() fails open, the returned customer will have id: null:
Console output
When fail-open triggers, you’ll see this in your server logs:
Monitor your logs for this message. If you see it, check status.useautumn.com for ongoing incidents.
SDK support
