API Circuit Breaker Pattern: Complete Implementation Guide
by API Status Check Team
API Circuit Breaker Pattern: Complete Implementation Guide
When an API dependency goes down, the worst thing your application can do is keep hammering it with requests. Each failed call consumes threads, memory, and time — cascading the failure from one service to your entire system.
The circuit breaker pattern prevents this cascade. Named after electrical circuit breakers that trip to prevent fires, software circuit breakers detect failures and stop sending requests to unhealthy services before they drag everything else down.
Why You Need Circuit Breakers
Without circuit breakers, a single failing dependency can take down your entire application:
Thread pool exhaustion: Requests pile up waiting for timeouts from the dead service, consuming all available threads.
Cascading failures: When Service A can't reach Service B, callers waiting on Service A also start failing, propagating the outage upstream.
Resource waste: Sending requests to a service that's clearly down wastes CPU, memory, and network bandwidth.
Slow recovery: Once the failing service comes back, the flood of queued requests can overwhelm it again immediately, preventing recovery.
A circuit breaker addresses all of these by failing fast when a dependency is unhealthy, giving it time to recover.
How Circuit Breakers Work
The circuit breaker operates as a state machine with three states:
Closed (Normal Operation)
In the closed state, requests pass through normally. The circuit breaker monitors success and failure rates in the background.
Client → Circuit Breaker (CLOSED) → API Service
↓
Monitors failures
When the failure rate exceeds a configured threshold (for example, 50% of requests fail within a 60-second window), the circuit breaker transitions to the open state.
Open (Failing Fast)
In the open state, the circuit breaker immediately rejects all requests without forwarding them to the failing service. This is the key benefit — your application gets an instant error response instead of waiting for a timeout.
Client → Circuit Breaker (OPEN) → ✗ Blocked
↓
Returns fallback/error immediately
The circuit stays open for a configured timeout period (typically 30-60 seconds), giving the failing service time to recover.
Half-Open (Testing Recovery)
After the timeout expires, the circuit breaker transitions to half-open. It allows a limited number of test requests through to check if the service has recovered.
Client → Circuit Breaker (HALF-OPEN) → API Service (test request)
↓
If success → CLOSED
If failure → OPEN (reset timer)
If the test requests succeed, the circuit closes and normal traffic resumes. If they fail, the circuit opens again for another timeout period.
Implementation in Node.js
Here's a production-ready circuit breaker implementation using the popular opossum library:
const CircuitBreaker = require('opossum');
const axios = require('axios');
// Define the function to protect
async function callPaymentAPI(orderId, amount) {
const response = await axios.post('https://api.payments.example.com/charge', {
orderId,
amount
}, { timeout: 5000 });
return response.data;
}
// Wrap it with a circuit breaker
const breaker = new CircuitBreaker(callPaymentAPI, {
timeout: 5000, // Max time a request can take
errorThresholdPercentage: 50, // Trip after 50% failures
resetTimeout: 30000, // Try again after 30 seconds
volumeThreshold: 10, // Minimum requests before tripping
rollingCountTimeout: 60000, // Window for measuring failures
rollingCountBuckets: 6, // Granularity of measurement
});
// Event handlers for monitoring
breaker.on('open', () => {
console.warn('Circuit OPENED - payment API is failing');
// Alert your monitoring system
});
breaker.on('halfOpen', () => {
console.info('Circuit HALF-OPEN - testing payment API');
});
breaker.on('close', () => {
console.info('Circuit CLOSED - payment API recovered');
});
breaker.on('fallback', (result) => {
console.info('Fallback executed', result);
});
// Define a fallback response
breaker.fallback((orderId, amount) => {
return {
status: 'queued',
message: 'Payment service temporarily unavailable. Your order has been queued.',
orderId,
retryAfter: 30
};
});
// Use it
async function processOrder(orderId, amount) {
try {
const result = await breaker.fire(orderId, amount);
return { status: 'success', ...result };
} catch (error) {
// This fires when both the call AND fallback fail
return { status: 'error', message: 'Unable to process payment' };
}
}
Building Your Own (No Library)
If you prefer not to add a dependency, here's a minimal circuit breaker:
class CircuitBreaker {
constructor(fn, options = {}) {
this.fn = fn;
this.state = 'CLOSED';
this.failureCount = 0;
this.successCount = 0;
this.failureThreshold = options.failureThreshold || 5;
this.resetTimeout = options.resetTimeout || 30000;
this.halfOpenMax = options.halfOpenMax || 3;
this.halfOpenSuccesses = 0;
this.nextAttempt = null;
this.fallbackFn = null;
}
fallback(fn) {
this.fallbackFn = fn;
return this;
}
async fire(...args) {
if (this.state === 'OPEN') {
if (Date.now() >= this.nextAttempt) {
this.state = 'HALF_OPEN';
this.halfOpenSuccesses = 0;
} else {
if (this.fallbackFn) return this.fallbackFn(...args);
throw new Error('Circuit is OPEN - request blocked');
}
}
try {
const result = await this.fn(...args);
this.onSuccess();
return result;
} catch (error) {
this.onFailure();
if (this.fallbackFn) return this.fallbackFn(...args);
throw error;
}
}
onSuccess() {
if (this.state === 'HALF_OPEN') {
this.halfOpenSuccesses++;
if (this.halfOpenSuccesses >= this.halfOpenMax) {
this.state = 'CLOSED';
this.failureCount = 0;
}
}
this.failureCount = Math.max(0, this.failureCount - 1);
}
onFailure() {
this.failureCount++;
if (this.failureCount >= this.failureThreshold || this.state === 'HALF_OPEN') {
this.state = 'OPEN';
this.nextAttempt = Date.now() + this.resetTimeout;
}
}
getState() {
return {
state: this.state,
failureCount: this.failureCount,
nextAttempt: this.nextAttempt
? new Date(this.nextAttempt).toISOString()
: null
};
}
}
// Usage
const paymentBreaker = new CircuitBreaker(callPaymentAPI, {
failureThreshold: 5,
resetTimeout: 30000,
halfOpenMax: 3
});
paymentBreaker.fallback(() => ({
status: 'queued',
message: 'Payment temporarily unavailable'
}));
const result = await paymentBreaker.fire(orderId, amount);
Implementation in Python
Using the pybreaker library:
import pybreaker
import requests
from datetime import datetime
# Custom listener for monitoring
class MonitoringListener(pybreaker.CircuitBreakerListener):
def state_change(self, cb, old_state, new_state):
print(f"[{datetime.now()}] Circuit '{cb.name}' changed "
f"from {old_state.name} to {new_state.name}")
def failure(self, cb, exc):
print(f"[{datetime.now()}] Circuit '{cb.name}' recorded failure: {exc}")
def success(self, cb):
print(f"[{datetime.now()}] Circuit '{cb.name}' recorded success")
# Create the circuit breaker
payment_breaker = pybreaker.CircuitBreaker(
fail_max=5, # Open after 5 failures
reset_timeout=30, # Try half-open after 30 seconds
exclude=[ValueError], # Don't count validation errors
listeners=[MonitoringListener()],
name="payment-api"
)
@payment_breaker
def charge_payment(order_id: str, amount: float) -> dict:
response = requests.post(
"https://api.payments.example.com/charge",
json={"orderId": order_id, "amount": amount},
timeout=5
)
response.raise_for_status()
return response.json()
# Usage with fallback
def process_payment(order_id: str, amount: float) -> dict:
try:
return charge_payment(order_id, amount)
except pybreaker.CircuitBreakerError:
# Circuit is open — return fallback
return {
"status": "queued",
"message": "Payment service temporarily unavailable",
"orderId": order_id,
"retryAfter": 30
}
except requests.RequestException as e:
# Request failed but circuit hasn't tripped yet
return {
"status": "error",
"message": str(e)
}
Using tenacity with Circuit Breaker Logic
For more control, combine tenacity retries with circuit breaking:
from tenacity import (
retry, stop_after_attempt, wait_exponential,
retry_if_exception_type, CircuitBreaker
)
cb = CircuitBreaker(
failure_threshold=5,
recovery_timeout=30,
expected_exception=requests.RequestException
)
@retry(
stop=stop_after_attempt(3),
wait=wait_exponential(multiplier=1, min=1, max=10),
retry=retry_if_exception_type(requests.RequestException),
before_sleep=lambda retry_state: cb.acquire()
)
def call_api_with_retry(url: str, payload: dict) -> dict:
cb.acquire()
try:
response = requests.post(url, json=payload, timeout=5)
response.raise_for_status()
cb.record_success()
return response.json()
except Exception as e:
cb.record_failure()
raise
Implementation in Java (Resilience4j)
Resilience4j is the modern standard for circuit breakers in Java:
import io.github.resilience4j.circuitbreaker.CircuitBreaker;
import io.github.resilience4j.circuitbreaker.CircuitBreakerConfig;
import io.github.resilience4j.circuitbreaker.CircuitBreakerRegistry;
import java.time.Duration;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
public class PaymentService {
private final CircuitBreaker circuitBreaker;
private final HttpClient httpClient;
public PaymentService() {
CircuitBreakerConfig config = CircuitBreakerConfig.custom()
.failureRateThreshold(50) // 50% failure rate trips
.slowCallRateThreshold(80) // 80% slow calls also trips
.slowCallDurationThreshold(Duration.ofSeconds(3))
.waitDurationInOpenState(Duration.ofSeconds(30))
.permittedNumberOfCallsInHalfOpenState(5)
.minimumNumberOfCalls(10) // Need 10 calls before evaluating
.slidingWindowType(CircuitBreakerConfig.SlidingWindowType.COUNT_BASED)
.slidingWindowSize(20) // Last 20 calls
.recordExceptions(IOException.class, TimeoutException.class)
.ignoreExceptions(IllegalArgumentException.class)
.build();
CircuitBreakerRegistry registry = CircuitBreakerRegistry.of(config);
this.circuitBreaker = registry.circuitBreaker("payment-api");
this.httpClient = HttpClient.newBuilder()
.connectTimeout(Duration.ofSeconds(5))
.build();
// Register event listeners
circuitBreaker.getEventPublisher()
.onStateTransition(event ->
System.out.println("Circuit state: " + event.getStateTransition()))
.onFailureRateExceeded(event ->
System.out.println("Failure rate exceeded: " + event.getFailureRate()))
.onSlowCallRateExceeded(event ->
System.out.println("Slow call rate exceeded: " + event.getSlowCallRate()));
}
public PaymentResult chargePayment(String orderId, double amount) {
return CircuitBreaker.decorateSupplier(circuitBreaker, () -> {
HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create("https://api.payments.example.com/charge"))
.header("Content-Type", "application/json")
.POST(HttpRequest.BodyPublishers.ofString(
String.format("{\"orderId\":\"%s\",\"amount\":%.2f}", orderId, amount)
))
.build();
HttpResponse<String> response = httpClient.send(request,
HttpResponse.BodyHandlers.ofString());
if (response.statusCode() >= 500) {
throw new RuntimeException("Server error: " + response.statusCode());
}
return parseResponse(response.body());
}).get();
}
}
Spring Boot Integration
// application.yml
resilience4j:
circuitbreaker:
instances:
paymentService:
registerHealthIndicator: true
slidingWindowSize: 20
failureRateThreshold: 50
waitDurationInOpenState: 30s
permittedNumberOfCallsInHalfOpenState: 5
minimumNumberOfCalls: 10
slowCallDurationThreshold: 3s
slowCallRateThreshold: 80
// Service class
@Service
public class PaymentService {
@CircuitBreaker(name = "paymentService", fallbackMethod = "paymentFallback")
public PaymentResult charge(String orderId, double amount) {
return paymentClient.charge(orderId, amount);
}
private PaymentResult paymentFallback(String orderId, double amount, Throwable t) {
return new PaymentResult("queued",
"Payment service temporarily unavailable. Order queued.", orderId);
}
}
Configuration Best Practices
Getting circuit breaker configuration right is critical. Too sensitive and it trips on normal variance; too lenient and it fails to protect you.
Failure Threshold
The failure threshold determines when the circuit opens. Start with these guidelines:
- Critical payment/auth APIs: 30-40% failure rate — trip early to protect revenue
- Non-critical APIs (analytics, recommendations): 60-70% — more tolerance for degradation
- Internal microservices: 50% — balanced default
Always combine with a volume threshold. You don't want the circuit tripping because 2 out of 3 requests failed during low traffic.
{
errorThresholdPercentage: 50, // Trip at 50% failure rate
volumeThreshold: 10, // But only after 10+ requests
rollingCountTimeout: 60000, // Measured over 60 seconds
}
Reset Timeout
The reset timeout controls how long the circuit stays open before testing recovery:
- Too short (5-10s): Service might not have recovered yet, leading to rapid open-close-open cycling
- Too long (5+ min): Your application runs degraded longer than necessary
- Sweet spot: 30-60 seconds for most APIs
Consider implementing exponential backoff for the reset timeout:
class AdaptiveCircuitBreaker extends CircuitBreaker {
constructor(fn, options) {
super(fn, options);
this.baseResetTimeout = options.resetTimeout || 30000;
this.consecutiveOpens = 0;
this.maxResetTimeout = options.maxResetTimeout || 300000;
}
onFailure() {
const wasOpen = this.state === 'OPEN';
super.onFailure();
if (this.state === 'OPEN' && !wasOpen) {
this.consecutiveOpens++;
// Exponential backoff: 30s, 60s, 120s, 240s, max 300s
this.resetTimeout = Math.min(
this.baseResetTimeout * Math.pow(2, this.consecutiveOpens - 1),
this.maxResetTimeout
);
}
}
onSuccess() {
super.onSuccess();
if (this.state === 'CLOSED') {
this.consecutiveOpens = 0;
this.resetTimeout = this.baseResetTimeout;
}
}
}
Timeout Configuration
The request timeout for individual calls through the circuit breaker:
- Set the circuit breaker timeout slightly above the API's normal P99 latency
- If the API normally responds in 200ms (P99: 800ms), set timeout to 2-3 seconds
- Never set it higher than your own API's timeout to callers
{
timeout: 3000, // 3 seconds — above normal P99, catches real slowdowns
}
Fallback Strategies
What happens when the circuit is open? Your fallback strategy determines user experience during outages.
Cached Response
Return the last known good response:
const cache = new Map();
breaker.fallback(async (userId) => {
const cached = cache.get(`user:${userId}`);
if (cached && Date.now() - cached.timestamp < 300000) { // 5 min cache
return { ...cached.data, _cached: true };
}
throw new Error('No cached data available');
});
// Update cache on successful calls
breaker.on('success', (result, latencyMs) => {
if (result.userId) {
cache.set(`user:${result.userId}`, {
data: result,
timestamp: Date.now()
});
}
});
Degraded Response
Return a simplified response with reduced functionality:
breaker.fallback((productId) => {
return {
productId,
price: null, // Can't fetch real-time price
available: true, // Assume available
estimatedDelivery: '3-5 business days', // Default estimate
_degraded: true,
_message: 'Some features temporarily unavailable'
};
});
Queue for Retry
Accept the request and process it asynchronously:
const retryQueue = [];
breaker.fallback(async (orderId, payload) => {
retryQueue.push({
orderId,
payload,
timestamp: Date.now(),
attempts: 0
});
return {
status: 'accepted',
message: 'Your request has been queued and will be processed shortly',
orderId,
estimatedProcessingTime: '2-5 minutes'
};
});
// Background processor
setInterval(async () => {
if (breaker.status === 'closed' && retryQueue.length > 0) {
const item = retryQueue.shift();
try {
await breaker.fire(item.orderId, item.payload);
} catch {
item.attempts++;
if (item.attempts < 3) retryQueue.push(item);
}
}
}, 10000);
Monitoring Circuit Breakers
Circuit breakers without monitoring are blind. You need to know when circuits trip and why.
Key Metrics to Track
Track these metrics for each circuit breaker:
- State transitions: Every open/close/half-open change with timestamps
- Failure rate: Rolling percentage over time
- Request volume: Total requests per window
- Rejection rate: Requests blocked while open
- Latency: Response time distribution (P50, P95, P99)
- Fallback usage: How often fallbacks execute
Prometheus Metrics Example
const { Registry, Counter, Gauge, Histogram } = require('prom-client');
class CircuitBreakerMetrics {
constructor(breakerName) {
this.stateGauge = new Gauge({
name: 'circuit_breaker_state',
help: 'Current state (0=closed, 1=open, 2=half-open)',
labelNames: ['breaker']
});
this.requestCounter = new Counter({
name: 'circuit_breaker_requests_total',
help: 'Total requests through circuit breaker',
labelNames: ['breaker', 'result'] // result: success, failure, rejected
});
this.stateChangeCounter = new Counter({
name: 'circuit_breaker_state_changes_total',
help: 'Number of state transitions',
labelNames: ['breaker', 'from', 'to']
});
this.latencyHistogram = new Histogram({
name: 'circuit_breaker_request_duration_seconds',
help: 'Request duration through circuit breaker',
labelNames: ['breaker'],
buckets: [0.01, 0.05, 0.1, 0.5, 1, 2, 5, 10]
});
this.name = breakerName;
}
attach(breaker) {
breaker.on('success', () => {
this.requestCounter.inc({ breaker: this.name, result: 'success' });
});
breaker.on('failure', () => {
this.requestCounter.inc({ breaker: this.name, result: 'failure' });
});
breaker.on('reject', () => {
this.requestCounter.inc({ breaker: this.name, result: 'rejected' });
});
breaker.on('open', () => {
this.stateGauge.set({ breaker: this.name }, 1);
});
breaker.on('close', () => {
this.stateGauge.set({ breaker: this.name }, 0);
});
breaker.on('halfOpen', () => {
this.stateGauge.set({ breaker: this.name }, 2);
});
}
}
Alerting Rules
Set up alerts for critical circuit breaker events:
# Prometheus alerting rules
groups:
- name: circuit-breaker-alerts
rules:
- alert: CircuitBreakerOpen
expr: circuit_breaker_state == 1
for: 1m
labels:
severity: warning
annotations:
summary: "Circuit breaker {{ $labels.breaker }} is OPEN"
description: "The circuit breaker has been open for over 1 minute"
- alert: CircuitBreakerFlapping
expr: increase(circuit_breaker_state_changes_total[10m]) > 5
labels:
severity: critical
annotations:
summary: "Circuit breaker {{ $labels.breaker }} is flapping"
description: "Circuit breaker has changed state more than 5 times in 10 minutes"
- alert: HighRejectionRate
expr: rate(circuit_breaker_requests_total{result="rejected"}[5m]) > 10
labels:
severity: warning
annotations:
summary: "High rejection rate on {{ $labels.breaker }}"
Circuit Breakers in API Gateways
API gateways are a natural place to implement circuit breakers since all traffic passes through them.
Kong Gateway
# Kong circuit breaker plugin configuration
plugins:
- name: circuit-breaker
config:
error_threshold_percentage: 50
min_calls_in_window: 20
window_size_in_seconds: 60
wait_duration_in_open_state: 30
permitted_calls_in_half_open: 5
error_status_codes:
- 500
- 502
- 503
- 504
fallback_response:
status_code: 503
content_type: "application/json"
body: '{"error": "Service temporarily unavailable", "retry_after": 30}'
AWS API Gateway with Lambda
// Lambda function with built-in circuit breaker
const { DynamoDB } = require('@aws-sdk/client-dynamodb');
const dynamo = new DynamoDB();
async function getCircuitState(serviceName) {
const result = await dynamo.getItem({
TableName: 'CircuitBreakerState',
Key: { serviceName: { S: serviceName } }
});
if (!result.Item) return { state: 'CLOSED', failures: 0 };
return {
state: result.Item.state.S,
failures: parseInt(result.Item.failures.N),
openedAt: result.Item.openedAt?.N
};
}
exports.handler = async (event) => {
const circuit = await getCircuitState('payment-api');
if (circuit.state === 'OPEN') {
const elapsed = Date.now() - parseInt(circuit.openedAt);
if (elapsed < 30000) {
return {
statusCode: 503,
body: JSON.stringify({
error: 'Service temporarily unavailable',
retryAfter: Math.ceil((30000 - elapsed) / 1000)
})
};
}
// Transition to half-open
}
// Forward request to backend...
};
Common Anti-Patterns
Not Setting a Volume Threshold
Without a minimum number of requests, the circuit trips on statistical noise:
// BAD: Trips if 1 out of 2 requests fail (50%)
{ errorThresholdPercentage: 50 }
// GOOD: Needs at least 10 requests before evaluating
{ errorThresholdPercentage: 50, volumeThreshold: 10 }
Using Circuit Breakers for Validation Errors
Don't count client errors (4xx) as circuit breaker failures — they indicate bad input, not service problems:
// BAD: Counts 400 Bad Request as a failure
async function callAPI(data) {
const response = await fetch(url, { body: JSON.stringify(data) });
if (!response.ok) throw new Error('Failed'); // All errors trip the circuit
}
// GOOD: Only count server errors
async function callAPI(data) {
const response = await fetch(url, { body: JSON.stringify(data) });
if (response.status >= 500) throw new Error('Server error');
if (response.status >= 400) return { error: await response.json() }; // Don't trip
return response.json();
}
Sharing Circuit Breakers Across Endpoints
Different endpoints on the same service can have different failure characteristics:
// BAD: One circuit for everything
const apiBreaker = new CircuitBreaker(callAPI);
// GOOD: Separate circuits for different endpoints
const authBreaker = new CircuitBreaker(callAuthAPI, {
failureThreshold: 3, // Auth is critical — trip fast
resetTimeout: 60000
});
const searchBreaker = new CircuitBreaker(callSearchAPI, {
failureThreshold: 10, // Search is less critical
resetTimeout: 15000
});
Not Testing Circuit Breaker Behavior
Your circuit breakers should be tested like any other critical code:
describe('PaymentCircuitBreaker', () => {
it('opens after threshold failures', async () => {
const mockAPI = jest.fn().mockRejectedValue(new Error('timeout'));
const breaker = new CircuitBreaker(mockAPI, {
failureThreshold: 3,
resetTimeout: 100
});
// Trigger 3 failures
for (let i = 0; i < 3; i++) {
try { await breaker.fire(); } catch {}
}
expect(breaker.getState().state).toBe('OPEN');
});
it('uses fallback when open', async () => {
const breaker = new CircuitBreaker(
() => Promise.reject(new Error('fail')),
{ failureThreshold: 1 }
);
breaker.fallback(() => ({ cached: true }));
try { await breaker.fire(); } catch {}
const result = await breaker.fire();
expect(result.cached).toBe(true);
});
it('recovers after reset timeout', async () => {
let shouldFail = true;
const breaker = new CircuitBreaker(
() => shouldFail ? Promise.reject(new Error()) : Promise.resolve('ok'),
{ failureThreshold: 1, resetTimeout: 100, halfOpenMax: 1 }
);
try { await breaker.fire(); } catch {}
expect(breaker.getState().state).toBe('OPEN');
shouldFail = false;
await new Promise(resolve => setTimeout(resolve, 150));
const result = await breaker.fire();
expect(result).toBe('ok');
expect(breaker.getState().state).toBe('CLOSED');
});
});
Circuit Breakers and API Monitoring
Circuit breakers and API monitoring tools like API Status Check complement each other:
- API monitoring tells you when a service is down globally
- Circuit breakers protect your specific application from that outage
When your monitoring detects an outage, you already know the circuit breaker is doing its job. When a circuit breaker trips but monitoring shows the service is healthy, you know the issue is on your side (network, configuration, or rate limiting).
Combining Both
// Use monitoring data to pre-emptively open circuits
const apiStatusCheck = require('apistatuscheck');
async function checkAndUpdateCircuit(serviceName, breaker) {
const status = await apiStatusCheck.getStatus(serviceName);
if (status.isDown && breaker.getState().state === 'CLOSED') {
// Pre-emptively open the circuit based on monitoring data
breaker.open();
console.log(`Pre-emptively opened circuit for ${serviceName} based on monitoring`);
}
}
Summary
The circuit breaker pattern is essential for any application that depends on external APIs. Key takeaways:
- Fail fast instead of waiting for timeouts — protect your resources
- Configure thoughtfully — thresholds, timeouts, and volume minimums all matter
- Implement fallbacks — cached data, degraded responses, or queuing
- Monitor everything — state transitions, failure rates, rejection counts
- Test your circuit breakers — they're critical infrastructure, treat them that way
- Combine with monitoring — circuit breakers protect locally, monitoring provides global visibility
Start with a simple implementation on your most critical API dependency. Once you see the benefits during the next outage (and there will be one), you'll want circuit breakers on everything.
Related Resources
API Status Check
Stop checking API status pages manually
Get instant email alerts when OpenAI, Stripe, AWS, and 100+ APIs go down. Know before your users do.
Free dashboard available · 14-day trial on paid plans · Cancel anytime
Browse Free Dashboard →