Platform · Reliability
Failures handled by policy, not by whoever is on call.
Retry policies decide which failures are retried, how long to wait and when to stop. Every attempt is chained to the last, budgets stop retry storms, and one alert reaches the right team when they run out.
Retry chain
PO-10482 → ERP orders API
Attempt 1
09:14:02
HttpRequestException · 503 Service Unavailable
Waiting 30 s
Group "Transient network errors" · exponential
Attempt 2
09:14:32
HttpRequestException · 503 Service Unavailable
Waiting 60 s
Budget: 2 of 5 for this message
Attempt 3
09:15:32
200 OK · response stored · budget released
Shared budget
Transient network errors
138 / 500
per message cap 5
When a shared total runs out, retries stop for the whole group and one alert goes to the handler you chose.
400 Bad Request → blocked
Group “Validation errors” never retries bad data.
Notifier → integrations team
Email via SMTP, or an HTTP call to your incident tool.
Groups by priority
The first enabled group whose result type and matchers apply decides: allow within a budget, or block.
Precise matchers
Exception type, contains, a regular expression with a 200 ms limit, or a JSON path condition on the response body.
Delay strategies
Fixed, linear or exponential delays, with a cap on the longest wait.
Two budgets
A cap per message and a total shared by the subscription, released when the subscription next succeeds.
Alerts routed once
Budget-exhausted alerts go through any handler, routed per subscription, group or policy, and never sent twice.
Manual and bulk retry
Retry one exchange, a selection or a whole filter of up to 500, after previewing the plan.
Policy as configuration
Say exactly what is safe to retry.
A group matches transient network failures and allows five attempts per message with exponential back-off, inside a shared total of 500 for the subscription.
- Unmatched failures are not retried by default
- Manual retries never spend a budget
- Every “no retry” records its reason
{
"name": "Transient network errors",
"priority": 1,
"enabled": true,
"appliesTo": ["Error"],
"matchers": [
{ "type": "exceptionType", "value": "HttpRequestException" },
{ "type": "contains", "value": "503:" }
],
"action": "Allow",
"budget": {
"maxAttemptsPerError": 5,
"maxAttemptsTotal": 500,
"delayStrategy": { "type": "exponential", "initialDelayMs": 30000,
"multiplier": 2, "maxDelayMs": 1800000 }
},
"alertMode": "Inherit"
}Test before it matters
Simulate a policy against real errors.
The test panel runs the unsaved draft against sample exception text or response bodies and shows each simulated attempt: the group that matched, whether it would retry, the delay and the reason.
- Usage per subscription and group
- Reset a counter or route one alert elsewhere
- Saving rules catch groups that could never work
Retry chains
Every attempt, one chain.
Each exchange can be retried once, so attempts form a chain you can follow, named by promoted properties, and retries continue from the newest attempt.
- “Latest attempt only” shows what still needs action
- Re-resolve adapter properties when configuration changed
- Waiting retries can be run now
Documentation
Written from the source code.
Every claim on this page links to documentation that is synced from the Bitween repository.
Explore the platform
More capabilities.
Put every integration on one governed pipeline.
Talk to the architects who build Bitween about your partners, systems and message volumes, or start from the docs and run it yourself today.