Provider Bindings

Configure how your AI workflows connect to providers with automatic failover.

Overview

Provider Bindings define how your workflows connect to AI providers and models. Each workflow must have at least one primary provider binding, and can optionally have fallback bindings for automatic failover during outages or rate limiting.

Why Provider Bindings Matter

Resilience: Automatic failover to backup providers if primary fails
Flexibility: Switch between models and providers without code changes
Cost optimization: Use cheaper fallback models for non-critical scenarios
Compliance: Route sensitive data to specific providers/regions

Key Concepts

Term	Definition
Binding	Configuration linking a workflow to a provider + model
Primary	Your default provider (required, minimum 1 per workflow)
Fallback	Backup provider(s) activated if primary fails (optional)
Model Class	Category of AI capability (LLM, embedding, vision, etc.)
Product	Specific AI model (e.g., GPT-4, Claude 2, Gemini Pro)

Binding Roles

Primary Provider

What it is: Your default, go-to provider for this workflow.

Rules:

✅ Every workflow must have at least one primary provider
✅ Can have multiple primary providers (for load balancing)
❌ Cannot delete the last primary provider (workflow would break)

When primary is used:

On every workflow execution (first attempt)
When all fallbacks have failed and primary recovers
When fallback is not configured

Example use case:

Workflow: "Customer Support Chatbot"
Primary: Claude 2 (Anthropic)
Reason: Best quality for nuanced customer queries

Fallback Provider

What it is: Backup provider activated when primary is unavailable.

Rules:

⚠️ Optional (but strongly recommended for critical workflows)
✅ Can have multiple fallbacks (evaluated in priority order)
✅ Must be a different provider OR different model from primary
⚠️ Cannot add fallback until at least one primary exists

When fallback is used:

Primary provider returns HTTP 5xx errors (server errors)
Primary provider rate limit exceeded (HTTP 429)
Primary provider times out (no response within threshold)
Primary provider returns specific error codes configured for fallback

Example use case:

Workflow: "Customer Support Chatbot"
Primary: Claude 2 (Anthropic)
Fallback 1: GPT-4 (OpenAI)
Fallback 2: Gemini Pro (Google)

If Anthropic is down → Try OpenAI
If OpenAI also fails → Try Google
If all fail → Return error to user

Priority order: If you have multiple fallbacks for the same model class, they're evaluated in ascending priority number order:

Priority 1 (first fallback)
Priority 2 (second fallback)
Priority 3 (third fallback)

Fallback Types

SignalBreak supports 3 fallback strategies:

1. None (No Fallback)

What it means: This binding has no fallback configured. If it fails, the workflow fails.

When to use:

Testing/development workflows
Non-critical internal tools
When 100% reliability not required

Risk: Single point of failure. If this provider goes down, your workflow stops working immediately.

2. Same Provider (Different Model)

What it means: Fallback to a different model from the same provider.

When to use:

Provider is generally reliable (low outage risk)
Cost optimization (fallback to cheaper model)
Quality tiering (fallback to faster but lower-quality model)

Example:

Primary: GPT-4 (OpenAI) ← Highest quality, expensive
Fallback: GPT-3.5 Turbo (OpenAI) ← Lower quality, 50% cheaper
Fallback Type: same_provider

Limitations:

If the entire provider has an outage (all models down), fallback won't help
Provider-level rate limits affect all models

3. Alternative Provider

What it means: Fallback to a different provider entirely.

When to use:

Maximum resilience required (critical workflows)
Compliance requires multi-provider strategy
Provider-specific outages are common
Different providers have different regional availability

Example:

Primary: Claude 2 (Anthropic)
Fallback: GPT-4 (OpenAI)
Fallback Type: alt_provider

Benefits:

True redundancy (different infrastructure, APIs, SLAs)
Survives provider-wide outages
Can route to different regions/jurisdictions if needed

Considerations:

Different providers may have different response formats
Prompt engineering may need tuning for each provider
Cost structures differ between providers

Model Classes

Bindings are organized by model class (the type of AI capability needed).

LLM (Large Language Model)

Use for:

Text generation (chatbots, content creation)
Question answering
Summarization
Translation
Code generation

Endpoint types:

chat (conversational format with system/user/assistant messages)
completion (simple prompt → response)

Examples:

GPT-4, GPT-3.5 Turbo (OpenAI)
Claude 2, Claude Instant (Anthropic)
Gemini Pro (Google)
Command (Cohere)

Embedding

Use for:

Semantic search
Document similarity
Clustering/classification
Recommendation systems

Endpoint type:

embeddings (text → vector representation)

Examples:

text-embedding-ada-002 (OpenAI)
embed-english-v3.0 (Cohere)
gecko@002 (Google)

Rerank

Use for:

Search result re-ranking
Relevance scoring
Query-document matching

Endpoint type:

rerank (query + documents → ranked list)

Examples:

rerank-english-v2.0 (Cohere)

Speech

Use for:

Speech-to-text (transcription)
Text-to-speech (voice synthesis)

Endpoint type:

speech (audio → text OR text → audio)

Examples:

Whisper (OpenAI)
Speech-to-Text v2 (Google)

Vision

Use for:

Image analysis
Object detection
OCR (optical character recognition)
Visual question answering

Endpoint type:

vision (image → description/analysis)

Examples:

GPT-4 Vision (OpenAI)
Gemini Pro Vision (Google)
Claude 3 (Anthropic)

Model Sources

SignalBreak supports 2 types of model sources:

Platform Models (Curated)

What they are: Officially supported AI models from major providers (curated by SignalBreak).

Characteristics:

✅ Pre-configured endpoints and pricing
✅ Automatic updates when providers change models
✅ Governance data (usage limits, terms of service, regional availability)
✅ Signal monitoring (deprecation notices, pricing changes)

Where they come from:

SignalBreak's curated provider directory
Updated regularly as providers release new models

Example:

Source: Platform
Model: GPT-4 Turbo (OpenAI)
Product ID: abc-123-platform-gpt4
Provider: OpenAI (provider_id: 1)

When to use:

You use major cloud AI providers (OpenAI, Anthropic, Google, etc.)
You want automatic governance tracking
You want to receive signals about model changes

Discovered Models (Self-Hosted)

What they are: AI models you host yourself or access via custom connections (detected via model discovery).

Characteristics:

✅ Full control over hosting and configuration
✅ No vendor lock-in
✅ Custom models (fine-tuned, specialized)
⚠️ Manual governance (you track your own usage, limits, terms)
⚠️ No automatic signals (you must monitor your own infrastructure)

Where they come from:

Your self-hosted connections (Ollama, vLLM, TGI, etc.)
Discovered via SignalBreak's model discovery process
Custom API endpoints you've configured

Example:

Source: Discovered
Model: llama-2-70b-chat (Self-hosted via Ollama)
Connection: ollama-prod-1
Discovered Model ID: xyz-789-discovered-llama2
Provider: Ollama (provider_id: 15)

When to use:

You run your own AI infrastructure (on-premises or cloud VMs)
You use specialized/fine-tuned models not available from major providers
You require full data sovereignty (no external API calls)
You have cost constraints (self-hosting is cheaper at scale)

Managing Bindings

View Current Bindings

Location: Workflow detail page → "Provider Bindings" card

What you see:

List of all bindings for this workflow
Each binding shows:
- Role badge: Primary (blue) or Fallback (gray)
- Provider name: e.g., "OpenAI (T1-Premium)"
- Model class: e.g., "LLM"
- Model name: e.g., "GPT-4 Turbo"
- Fallback type: None, Same Provider, or Alt Provider

Indicators:

Blue badge: Primary provider
Gray badge: Fallback provider
No delete button on last primary: Cannot remove if it's the only primary

Add a Fallback

Prerequisites:

✅ Workflow has at least one primary provider configured
✅ You've selected providers on the Providers page first

Steps:

Navigate to workflow detail page
Scroll to "Provider Bindings" card
Click "+ Add Fallback" button
In dialog:
- Model Class: Select (e.g., LLM, embedding)
- Provider: Choose from your selected providers
- Model: Select specific model (dropdown auto-populates)
- Fallback Type: Choose (same_provider or alt_provider)
Click "Add Binding"
Binding appears in list immediately

Validation:

Cannot add duplicate binding (same workflow + provider + model class)
Cannot add fallback if no primary exists yet
Model must be enabled in your account (see Models page)

Change Provider or Model

You can edit existing bindings in-place:

Change Provider:

Click provider dropdown on existing binding
Select different provider
Auto-saves immediately
Note: Switching provider clears the selected model (you must re-select)

Change Model:

Click model dropdown on existing binding
Select different model (platform or discovered)
Auto-saves immediately
Note: Model must be from the same provider and model class

Change Fallback Type:

Click fallback type dropdown on existing binding
Select: None, Same Provider, or Alt Provider
Auto-saves immediately

Toggle Primary/Fallback Role

You can change a binding's role dynamically:

Steps:

Locate binding in "Provider Bindings" card
Click "Role" toggle (shows current role)
Select Primary or Fallback
Role changes immediately

Constraints:

❌ Cannot change last primary to fallback (workflow would have no primary)
✅ Can change fallback to primary anytime
✅ Can change primary to fallback if at least one other primary exists

Use case:

Before failover testing:
- Primary: Claude 2
- Fallback: GPT-4

During testing (force GPT-4):
- Toggle GPT-4 to Primary
- Toggle Claude 2 to Fallback

After testing (restore):
- Toggle back to original roles

Delete a Binding

Steps:

Click red trash icon next to binding
Confirm deletion in prompt
Binding removed immediately

Constraints:

❌ Cannot delete the last primary provider (error: "Cannot remove the last primary provider for this workflow")
✅ Can delete any fallback binding anytime
✅ Can delete a primary binding if at least one other primary exists

What happens to data:

Binding is soft-deleted (marked is_active = false)
Historical usage data retained (for audit trail)
Workflow stops using this provider immediately

Fallback Behavior

When Fallback is Triggered

SignalBreak automatically fails over to fallback providers in these scenarios:

Condition	Example	Action
HTTP 5xx error	Primary returns 503 Service Unavailable	Immediately try fallback
Rate limit (429)	Primary returns 429 Too Many Requests	Try fallback, retry primary after backoff
Timeout	Primary doesn't respond within 30s	Try fallback
Connection error	Primary host unreachable	Try fallback
Invalid API key	Primary returns 401 Unauthorized	Log error, try fallback (may indicate account issue)

Not triggered by:

❌ HTTP 4xx client errors (400, 404, 422) → These are your fault, not provider's
❌ Successful responses with empty content → Provider worked, just no output
❌ Low-quality responses → Fallback is for availability, not quality

Fallback Order

With multiple fallbacks, SignalBreak tries them in priority order:

1. Primary (priority 1) → Fails
2. Fallback 1 (priority 2) → Fails
3. Fallback 2 (priority 3) → Fails
4. Fallback 3 (priority 4) → Succeeds ✅

Total time: 4 attempts, workflow succeeds

If all fail:

1. Primary → Fails
2. Fallback 1 → Fails
3. Fallback 2 → Fails
4. Fallback 3 → Fails
5. Return error to user ❌

Error: "All providers unavailable. Please try again later."

Fallback Recovery

Primary provider automatically returns to use when healthy:

Time: 10:00 AM - Primary (Claude) fails
Time: 10:01 AM - Workflow fails over to Fallback (GPT-4)
Time: 10:00 AM - 11:00 AM - All requests use GPT-4
Time: 11:00 AM - Primary (Claude) recovers
Time: 11:01 AM - Next request tries Primary first
Time: 11:01 AM onwards - Primary back in use (fallback on standby)

Recovery detection:

Every N requests, SignalBreak retries the primary (even if fallback is working)
If primary succeeds, it returns to primary role
If primary still fails, continues using fallback

Why this matters:

You always prefer your primary provider (you chose it for a reason: cost, quality, compliance)
Fallback is temporary, not permanent
Automatic recovery means no manual intervention needed

Integration Patterns

Bindings support 3 integration patterns (how your workflow calls the AI provider):

Synchronous (sync)

What it is: Wait for AI response before continuing.

Flow:

1. Send request to provider
2. Wait for response (blocking)
3. Process response
4. Return to user

When to use:

Real-time user interactions (chatbots, live search)
Low-latency requirements (<5 seconds)
Simple request-response workflows

Characteristics:

Fast (seconds)
Blocking (user waits)
Best for: Chat, Q&A, instant analysis

Example: Customer support chatbot (user expects immediate response)

Asynchronous (async)

What it is: Submit job, poll for completion, retrieve result later.

Flow:

1. Submit job to provider (returns job_id)
2. Return immediately to user ("Processing...")
3. Poll job status (every N seconds)
4. When complete, retrieve result
5. Notify user (webhook, email, UI update)

When to use:

Long-running tasks (>30 seconds)
Batch processing
Non-urgent workflows

Characteristics:

Slow (minutes to hours)
Non-blocking (user can do other things)
Best for: Document analysis, video transcription, large batch embeddings

Example: Legal contract review (upload 100-page contract, get analysis in 5 mins)

Batch

What it is: Process multiple items in a single API call (bulk operations).

Flow:

1. Collect 100 items
2. Send all 100 in single batch request
3. Wait for batch response
4. Process all 100 results at once

When to use:

High-volume processing
Cost optimization (batch pricing usually cheaper)
Offline workflows (nightly jobs, data pipelines)

Characteristics:

Efficient (one API call for many items)
Cost-effective (often 50% cheaper than individual calls)
Best for: Embeddings generation, bulk classification, data enrichment

Example: E-commerce catalog (generate embeddings for 10,000 product descriptions nightly)

Provider Limits by Plan

SignalBreak enforces provider limits based on your subscription tier:

Plan	Max Providers	Bindings per Workflow	Notes
Free	2	Unlimited	Good for testing
Starter	5	Unlimited	Small teams
Professional	15	Unlimited	Mid-size teams
Enterprise	Unlimited	Unlimited	Large organizations

What counts as a provider:

Each unique provider (OpenAI, Anthropic, Google, etc.) you use
Counted once per tenant (not per workflow)
Self-hosted providers count towards limit

What happens when you hit the limit:

Binding creation is blocked (HTTP 403 error)
Error message: "Provider limit reached. Please upgrade your plan."
Existing bindings remain active (read-only)

How to manage limits:

Remove unused providers from Settings → Providers
Archive workflows using rare providers
Upgrade plan if consistently hitting limits

Check your usage:

Navigate to Settings → Billing
View "Providers" usage meter
Shows: X / Y providers used (Z% of quota)

Best Practices

1. Always Configure Fallbacks for Critical Workflows

Why: Single provider outages are common (monthly occurrence for major providers).

Recommended strategy:

Critical workflows (customer-facing, revenue-generating):
- Primary: Your preferred provider (best quality)
- Fallback 1: Second-best provider (different infrastructure)
- Fallback 2: Third provider (last resort, may compromise quality)

Non-critical workflows (internal tools, analytics):
- Primary only (fallback not worth the complexity)

Cost/benefit:

Adding fallbacks: 5 mins of configuration
Impact of outage without fallback: Hours of downtime, lost revenue, angry customers
ROI: Extremely high for critical workflows

2. Test Your Fallbacks Regularly

Why: Fallbacks are useless if they don't work when you need them.

How to test:

Toggle method (recommended):
- Change fallback to primary role (forces it to be used)
- Run test queries through workflow
- Verify output quality acceptable
- Toggle back to original roles
Scenario method:
- Create scenario: "What if [Primary Provider] is down?"
- Execute scenario
- Review impacts and mitigations
- Verify fallback is configured correctly

Test frequency:

Monthly: For critical workflows
Quarterly: For non-critical workflows
After any provider/model changes

3. Use Different Providers for Fallbacks (Not Just Different Models)

Why: Provider-wide outages affect all models from that provider.

Example:

❌ BAD:
Primary: GPT-4 (OpenAI)
Fallback: GPT-3.5 (OpenAI)
Risk: If OpenAI has outage, both fail

✅ GOOD:
Primary: GPT-4 (OpenAI)
Fallback: Claude 2 (Anthropic)
Risk: If OpenAI has outage, Anthropic still works

When same-provider fallback makes sense:

Cost optimization (fallback to cheaper model during rate limits)
Quality tiering (fallback to faster but lower-quality model)
You've verified the provider has excellent uptime SLA

4. Match Model Capabilities to Use Case

Why: Different models excel at different tasks. Choose appropriately.

Examples:

Use Case	Recommended Primary	Recommended Fallback	Why
Customer support chatbot	Claude 2 (Anthropic)	GPT-4 (OpenAI)	Claude excels at nuanced conversation, GPT-4 is reliable fallback
Code generation	GPT-4 (OpenAI)	Gemini Pro (Google)	GPT-4 best for complex code, Gemini good fallback
Document summarization	Claude 2 (Anthropic)	GPT-3.5 (OpenAI)	Claude handles long docs well, GPT-3.5 is cheap fallback
Simple classification	GPT-3.5 (OpenAI)	Gemini Pro (Google)	Cheap and fast, Gemini if OpenAI rate-limited

Avoid:

Using vision models for text-only tasks
Using embedding models for chat (they don't generate text)
Using expensive models (GPT-4) for simple tasks where GPT-3.5 would suffice

5. Monitor Fallback Usage

Why: Frequent fallback usage indicates a problem with your primary provider.

What to monitor:

Fallback trigger rate: % of requests that use fallback vs. primary
Provider availability: Uptime % for each provider
Cost impact: Is fallback more expensive? (May indicate you should switch primary)

Red flags:

>10% fallback rate: Primary provider unreliable, consider switching
Fallback faster than primary: Consider swapping roles
Fallback cheaper than primary: Re-evaluate provider strategy

Where to monitor:

Dashboard → Workflows → [Workflow] → Metrics
Dashboard → Providers → [Provider] → Health
Settings → Audit Logs (filter by workflow)

6. Document Prompt Differences Between Providers

Why: Different providers have different prompt formats and behaviors.

What to document:

System message support: Does this provider support system messages? (OpenAI yes, some others no)
Max token limits: How long can prompts be? (varies by model)
Function calling: Does this provider support tool use/function calling?
Prompt tuning required: Did you need to adjust prompts when switching providers?

Example documentation:

markdown

## Workflow: Customer Support Chatbot

**Primary: Claude 2 (Anthropic)**
- System message: "You are a helpful customer support agent..."
- Max tokens: 100,000
- Tone: Empathetic and detailed
- Prompt engineering: Works well with multi-turn conversations

**Fallback: GPT-4 (OpenAI)**
- System message: Same as Claude (GPT-4 supports system messages)
- Max tokens: 8,000 (SHORTER! May truncate long conversations)
- Tone: More concise, less empathetic
- Prompt engineering: Add explicit "Be empathetic" instruction

**Fallback Behavior:**
If Claude is down, GPT-4 takes over. User experience slightly degraded
(shorter responses, less empathy) but functional.

Troubleshooting

Problem: "Cannot Add Fallback" Button is Disabled

Possible causes:

No primary provider exists yet
- Solution: Add a primary provider first (create new binding, select "Primary" role)
No providers selected
- Solution: Go to Settings → Providers, select at least 2 providers
Feature gate hit (provider limit reached)
- Solution: Upgrade plan or remove unused providers

How to diagnose:

Hover over disabled button (tooltip shows reason)
Check "Provider Bindings" card: Do you see at least one "Primary" badge?
Check Settings → Billing: Are you at provider limit?

Problem: "Duplicate Binding" Error

Meaning: You already have a binding for this workflow + provider + model class combination.

Example:

Existing binding:
- Workflow: "Customer Support"
- Provider: OpenAI
- Model Class: LLM

Attempted new binding (fails):
- Workflow: "Customer Support"
- Provider: OpenAI
- Model Class: LLM

Solution:

Option 1: Change the model on existing binding (not a duplicate, same binding, different model)
Option 2: Choose a different provider for your new binding
Option 3: Choose a different model class (e.g., add an embedding binding, not another LLM binding)

Why this rule exists:

Prevents accidental duplicates
Keeps binding configuration clear (one binding per workflow+provider+class)

Problem: "Model Not Enabled" Error

Meaning: The model you selected is not enabled in your SignalBreak account.

Why this happens:

You haven't enabled this model on the Models page yet
Model was disabled (you turned it off after it was bound)
Model was removed from provider's catalog

Solution:

Navigate to Dashboard → Models
Find the model (use search or filter by provider)
Click "Enable" toggle
Return to workflow, try adding binding again

For discovered models:

Navigate to Dashboard → Connections
Find your connection (e.g., "ollama-prod-1")
Click "Sync Models" to refresh
Enable the discovered model
Return to workflow, try adding binding again

Problem: Fallback Never Triggers

Symptoms:

Primary provider fails (you see errors)
But fallback is not used (errors persist)
Workflow returns errors to user

Possible causes:

1. Fallback binding inactive or deleted

Check: Go to workflow → Provider Bindings
Verify fallback binding exists and shows "Fallback" badge
Solution: Re-add fallback binding if missing

2. Fallback has same failure mode

Check: Are both primary AND fallback providers down?
Verify: Check Dashboard → Providers → [Provider] → Health
Solution: Add fallback from different provider

3. Error is 4xx (client error), not 5xx (server error)

Check: View error logs → What HTTP status code?
Fallback only triggers on 5xx errors (server issues)
4xx errors = your problem (bad API key, malformed request, etc.)
Solution: Fix client error (not a provider issue)

4. Fallback type misconfigured

Check: Fallback type = "None"?
Solution: Change fallback type to "same_provider" or "alt_provider"

Problem: "Cannot Delete Last Primary Provider"

Meaning: You tried to delete the only primary provider for this workflow.

Why this is blocked:

Workflows MUST have at least one primary provider
Deleting the last primary would break the workflow (no provider to call)

Solutions:

Option 1: Add another primary first

Add a new binding with role = "Primary"
Now you have 2 primary providers
Delete the original primary

Option 2: Change role to fallback first

Toggle the primary binding to "Fallback" role
This requires another primary to exist first (see Option 1)

Option 3: Delete the entire workflow

If you truly don't need this workflow anymore
Navigate to workflow detail page
Click "Delete Workflow" (top right, red button)
Confirm deletion
Workflow AND all bindings are deleted

Problem: Fallback is More Expensive Than Primary

Symptoms:

You configured fallback for cost optimization
But your costs increased (unexpected)
Billing shows high usage of fallback provider

Cause: Fallback is being used MORE than expected (indicates primary provider issues).

Diagnosis:

Check fallback trigger rate:
- Dashboard → Workflows → [Workflow] → Metrics
- Look for "Fallback Usage %" metric
If >10%: Primary provider is unreliable

Solutions:

Short-term:

Check primary provider health: Dashboard → Providers → [Provider] → Health
Review API key validity (expired? rate-limited?)
Check primary provider status page (external link)

Long-term:

Swap roles: If fallback is better, make it primary
Switch provider: Choose more reliable primary
Add rate limit handling: Configure backoff/retry before failing over

FAQ

Can I have multiple primary providers for the same workflow?

Yes. You can have multiple bindings with role = "Primary" for load balancing.

How it works:

SignalBreak round-robins between primary providers
If one primary fails, tries the next primary
Only falls back to "Fallback" role after all primaries fail

Example:

Primary 1: GPT-4 (OpenAI)
Primary 2: Claude 2 (Anthropic)
Fallback: Gemini Pro (Google)

Load balancing:
Request 1 → GPT-4
Request 2 → Claude 2
Request 3 → GPT-4
Request 4 → Claude 2

If GPT-4 fails:
Request 5 → Claude 2 (skip failed primary)
Request 6 → Claude 2
Request 7 → GPT-4 (retry periodically)

Use case: Distribute load across providers to avoid rate limits.

What happens if I delete a provider I'm using in bindings?

Short answer: The binding becomes "orphaned" but still works (until you manually delete it).

What happens:

You go to Settings → Providers
You unselect "OpenAI" (remove from your selected providers)
Bindings using OpenAI continue to work (they're not automatically deleted)
But you can't create NEW bindings with OpenAI (it's not in your selected list anymore)

To fully remove:

Delete all bindings using that provider (go to each workflow, delete bindings)
Then unselect provider from Settings → Providers

Why it works this way:

Prevents accidental breakage (deleting provider doesn't cascade to workflows)
You must explicitly delete bindings (safer)

Can I use the same model for both primary and fallback?

Technically yes, but not recommended.

What happens:

Primary: GPT-4 (OpenAI)
Fallback: GPT-4 (OpenAI)
Fallback Type: same_provider

Result:

If GPT-4 fails (rate limit, outage), fallback to... GPT-4 again (same endpoint, same problem)
Fallback will also fail
No resilience benefit

Better approach:

Primary: GPT-4 (OpenAI)
Fallback: Claude 2 (Anthropic)
Fallback Type: alt_provider

When same-model fallback makes sense:

Never (it's always better to use a different model or different provider)

Do I need fallbacks for every workflow?

No. Fallbacks are optional. Use them strategically based on workflow criticality.

Decision matrix:

Workflow Type	Fallback Needed?	Why
Customer-facing (chatbots, live support)	✅ YES	Downtime = lost customers
Revenue-critical (fraud detection, pricing)	✅ YES	Downtime = lost revenue
Compliance-sensitive (legal, healthcare)	✅ YES	Regulatory requirements
Internal tools (meeting summaries, drafts)	⚠️ MAYBE	Nice to have, not critical
Batch jobs (nightly analytics, reports)	❌ NO	Can retry later
Development/testing	❌ NO	Not production, doesn't matter

Rule of thumb:

If downtime costs >$100/hour: Add fallback
If downtime is inconvenience only: Skip fallback

How long does it take to fail over to fallback?

Typical timeline:

00:00 - Request sent to primary provider
00:30 - Primary times out (30 second timeout)
00:30 - Fallback decision: Try fallback
00:31 - Request sent to fallback provider
00:32 - Fallback responds (1 second response time)
00:32 - Total elapsed: 32 seconds

Factors:

Primary timeout: 30 seconds (configurable in enterprise plans)
Fallback decision: <100ms (negligible)
Fallback response: Depends on fallback provider (usually 1-3 seconds)

Optimization:

Use shorter timeout for primary (e.g., 10 seconds) if fallback is fast
Use async pattern for long-running tasks (don't block user)

Can I set fallback based on error type (not all errors)?

Not currently. Fallback triggers on all 5xx errors + timeouts + rate limits.

Current behavior:

HTTP 500 (Internal Server Error) → Fallback
HTTP 503 (Service Unavailable) → Fallback
HTTP 504 (Gateway Timeout) → Fallback
HTTP 429 (Rate Limit) → Fallback
Connection timeout → Fallback

Future feature:

Custom fallback rules (e.g., "only fallback for 503 errors, not 500")
Error-specific fallback providers (e.g., "use Provider A for rate limits, Provider B for outages")

Workaround:

Use middleware in your application to detect specific errors
Route to specific workflows based on error type

Workflows: Create and configure AI workflows before adding provider bindings
Providers: Select and manage AI providers available for bindings
Models: Enable specific models before using them in bindings
Scenarios: Test resilience by simulating provider outages with configured fallbacks
Signals: Receive alerts when providers deprecate models or change pricing

Support

Need help with provider bindings?

📧 Email: support@signal-break.com
💬 Live Chat: Click chat icon (bottom right) for instant support
📚 Knowledge Base: docs.signal-break.com
🎥 Video Tutorial: Configuring Provider Bindings (8 mins)

Common requests:

Help choosing primary vs. fallback providers for my use case
Troubleshooting fallback not triggering
Optimizing provider costs with smart fallback strategies
Configuring custom timeout and retry logic (Enterprise feature)

Enterprise support:

Dedicated binding architecture review session
Custom fallback rules and error handling
SLA-based provider selection guidance

Last updated: January 2025

Provider Bindings ​

Overview ​

Why Provider Bindings Matter ​

Key Concepts ​

Binding Roles ​

Primary Provider ​

Fallback Provider ​

Fallback Types ​

1. None (No Fallback) ​

2. Same Provider (Different Model) ​

3. Alternative Provider ​

Model Classes ​

LLM (Large Language Model) ​

Embedding ​

Rerank ​

Speech ​

Vision ​

Model Sources ​

Platform Models (Curated) ​

Discovered Models (Self-Hosted) ​

Managing Bindings ​

View Current Bindings ​

Add a Fallback ​

Change Provider or Model ​

Toggle Primary/Fallback Role ​

Delete a Binding ​

Fallback Behavior ​

When Fallback is Triggered ​

Fallback Order ​

Fallback Recovery ​

Integration Patterns ​

Synchronous (sync) ​

Asynchronous (async) ​

Batch ​

Provider Limits by Plan ​

Best Practices ​

1. Always Configure Fallbacks for Critical Workflows ​

2. Test Your Fallbacks Regularly ​

3. Use Different Providers for Fallbacks (Not Just Different Models) ​

4. Match Model Capabilities to Use Case ​

5. Monitor Fallback Usage ​

6. Document Prompt Differences Between Providers ​

Troubleshooting ​

Problem: "Cannot Add Fallback" Button is Disabled ​

Problem: "Duplicate Binding" Error ​

Problem: "Model Not Enabled" Error ​

Problem: Fallback Never Triggers ​

Problem: "Cannot Delete Last Primary Provider" ​

Problem: Fallback is More Expensive Than Primary ​

FAQ ​

Can I have multiple primary providers for the same workflow? ​

What happens if I delete a provider I'm using in bindings? ​

Can I use the same model for both primary and fallback? ​

Do I need fallbacks for every workflow? ​

How long does it take to fail over to fallback? ​

Can I set fallback based on error type (not all errors)? ​

Related Features ​

Support ​

Provider Bindings

Overview

Why Provider Bindings Matter

Key Concepts

Binding Roles

Primary Provider

Fallback Provider

Fallback Types

1. None (No Fallback)

2. Same Provider (Different Model)

3. Alternative Provider

Model Classes

LLM (Large Language Model)

Embedding

Rerank

Speech

Vision

Model Sources

Platform Models (Curated)

Discovered Models (Self-Hosted)

Managing Bindings

View Current Bindings

Add a Fallback

Change Provider or Model

Toggle Primary/Fallback Role

Delete a Binding

Fallback Behavior

When Fallback is Triggered

Fallback Order

Fallback Recovery

Integration Patterns

Synchronous (sync)

Asynchronous (async)

Batch

Provider Limits by Plan

Best Practices

1. Always Configure Fallbacks for Critical Workflows

2. Test Your Fallbacks Regularly

3. Use Different Providers for Fallbacks (Not Just Different Models)

4. Match Model Capabilities to Use Case

5. Monitor Fallback Usage

6. Document Prompt Differences Between Providers

Troubleshooting

Problem: "Cannot Add Fallback" Button is Disabled

Problem: "Duplicate Binding" Error

Problem: "Model Not Enabled" Error

Problem: Fallback Never Triggers

Problem: "Cannot Delete Last Primary Provider"

Problem: Fallback is More Expensive Than Primary

FAQ

Can I have multiple primary providers for the same workflow?

What happens if I delete a provider I'm using in bindings?

Can I use the same model for both primary and fallback?

Do I need fallbacks for every workflow?

How long does it take to fail over to fallback?

Can I set fallback based on error type (not all errors)?

Related Features

Support