Realtime

RealtimeKit usage is charged according to the pricing model below:

Note

RealtimeKit participant and export usage is measured in minutes. In contrast, Realtime SFU, MoQ Relay, and TURN usage is measured in GB of egress. RealtimeKit transcription uses Workers AI pricing.

To estimate your RealtimeKit costs, refer to the RealtimeKit pricing calculator ↗︎.

The included usage applies to all accounts, including Free and Enterprise accounts.

Feature	Included per month	Price after included usage
Audio/Video Participant	10,000 minutes	$0.002 / minute
Audio-Only Participant	10,000 minutes	$0.0005 / minute
Export (recording, RTMP or HLS streaming)	100 minutes	$0.010 / minute
Export (recording, RTMP or HLS streaming, audio only)	100 minutes	$0.003 / minute
Export (Raw RTP) into R2	100 minutes	$0.0005 / minute
Transcription (Real-time)	See Workers AI pricing	Standard model pricing via Workers AI

Whether a participant is an audio-only participant or an audio/video participant is determined by the Meeting Type of their preset.

Realtime billing is based on data sent from Cloudflare to your application. The SFU and TURN services cost $0.05 per GB of egress.

The first 1,000 GB each month is free. SFU and TURN share this allowance; they do not have independent free tiers. Realtime usage appears as a single line item on your Cloudflare bill.

SFU

Traffic from Cloudflare to clients incurs egress charges. Traffic published into Cloudflare is free, including when no client subscribes to that publication.

WebSocket adapter

WebSocket adapter usage is tracked in Realtime billing. Traffic from Cloudflare to your WebSocket endpoint follows the Realtime egress rate and shares the Realtime free tier. Audio ingested from a WebSocket endpoint into the SFU is not charged as ingress.

The adapter close response's bytesProcessed field is an operational statistic. It is not the authoritative billed-usage total.

Workers, Durable Objects, Containers, and AI services used by an application have their own pricing.

TURN

Traffic between Realtime TURN and Realtime SFU or Cloudflare Stream WHIP/WHEP is not charged twice. Refer to the TURN FAQ for the traffic paths measured for TURN billing.

RealtimeKit applies limits to API requests and SDK operations. Use these values when designing your application.

API rate limits

RealtimeKit API requests count toward the global Cloudflare API limit, which applies across all api.cloudflare.com API requests. Recording APIs are subject to a separate limit.

API	Limit
All RealtimeKit APIs	3,500 requests per five minutes
Recording APIs	1,000 requests per 50 seconds

SDK rate limits

Each participant has a separate limit for SDK operations during an active session. Limits are not shared across participants or applied to your app as a whole. For example, in a two-participant meeting, each participant can send up to 180 text messages per minute.

Operation	Limit
Write to a meeting key-value store (set(), update(), delete(), bulkSet(), bulkDelete())	5 invocations per second
Broadcast a message (broadcastMessage())	5 invocations per second
Send a text message (sendTextMessage())	180 invocations per minute
Send a message (sendMessage())	180 invocations per minute
Send an image (sendImageMessage())	20 invocations per minute
Send a file (sendFileMessage())	20 invocations per minute
Fetch connected meetings (getConnectedMeetings())	60 invocations per minute
Fetch meeting participants (getAllJoinedPeers())	10 invocations per minute
Update participant permissions (updatePermissions())	1,000 invocations per minute

Data retention

For the retention periods for recordings, chat, transcripts, analytics, and webhook logs, refer to Data retention.

These limits apply to Realtime SFU resources. Application limits such as room admission or a device's viewer cap are separate policies.

API and resource limits

The API limits are:

Resource or operation	Limit
API requests per session	50 requests per second. The rate limit is per session rather than per app
Tracks added in one API request	Up to 64
Tracks in a session	No fixed upper bound. Endpoint and connection capacity impose practical limits
WebSocket adapters created or closed in one request	One to four track entries
Reply access to a publisher DataChannel	At most one subscriber with canReply
WebSocket audio ingest message	32 KB including serialized packet overhead

Distribute larger track batches across multiple calls and serialize mutations on each session. Inspect per-item results before retrying a partially successful batch.

Inactivity timeout

Apply each timeout to its resource and condition:

Condition	Timeout	Result
A media track receives no incoming media packets	30 seconds	The track is garbage-collected. Restore an expired publication and rebuild its subscriptions.
A session loses WebRTC connectivity	30-second session/track reuse window	Reuse requires a viable connection and resources. Replace failed or closed connections immediately, or reconnect with a new session after the window.
A remote DataChannel uses waitForAck: true	First subscriber message within 30 seconds of allocation	Without it, the gated channel closes. Create a new subscription. Refer to subscriber readiness.

For expiry before a session's first connection, follow session setup guidance. The media inactivity timeout does not define the lifetime of a connected session without media or a DataChannel-only connection. Close resources when finished.

Application heartbeat expiry does not mean WebRTC disconnected. Media that keeps arriving does not meet the inactivity condition. Use close results and recovery guidance to decide whether cleanup is complete or a resource can be reused.

PeerConnection requirements

Operations that require an established transport wait up to five seconds for connectivity before timing out. Complete initial transport negotiation before those operations. The connection recipes show where to apply SDP and wait for connectivity.

Adapter recovery

For WebRTC-to-WebSocket streaming, the SFU retries the same endpoint for up to 15 seconds after a temporary disconnect. An exhausted reconnect window closes the adapter. Ingest adapters do not automatically reconnect.

Refer to WebSocket adapter reconnect for buffering, delivery behavior, and application recovery.

Supported codecs

Realtime SFU supports these media-track codecs:

Media	Codecs
Video	H.264, H.265, VP8, VP9, AV1
Audio	Opus, G.711 A-law, G.711 µ-law

Endpoint support varies by WebRTC implementation. WebSocket adapters have their own format and direction constraints, including PCM audio and JPEG video output.

Usage allowance

Refer to pricing for egress charging and the shared monthly free tier.