Why does Jitsi end after 5 minutes?

Start with the message, not just the stopwatch

A call that stops after five minutes is a symptom, not a diagnosis. Check the full meeting server address, whether the call is embedded in another product, and any warning shown before it closes. The reviewed Jitsi Meet source includes two different mechanisms that can produce a five-minute boundary: a conditional embedding cutoff and an optional server-side room timer. [S2][S4]

When meet.jit.si is embedded in another website

Jitsi’s official embedding page says meet.jit.si is no longer the service for this use and points integrators to JaaS. An older tutorial that embeds the free public endpoint is not a commitment that the resulting integration is supported for production. [S1]

The pinned Jitsi Meet 11248 client defines IFRAME_DISABLED_TIMEOUT_MINUTES = 5. Its embedding check considers deployment configuration, the client context and exceptions. When that check applies, the web client warns and later redirects to a closing page; the native-client branch hangs up. This is not a timer applied to every Jitsi meeting. [S2]

Recommended next steps for an organizer:

1. Ask the website or learning-platform operator which Jitsi server it uses. The application’s address can differ from the embedded meeting’s address. The IFrame API selects its meeting server through the domain argument. [S5]
2. Record the warning and approximate elapsed time, without sharing private invitation URLs or tokens.
3. For an immediate session, use an organizer-approved direct meeting link, if available. Opening meet.jit.si directly still leaves its public 95-minute policy in place. [S3]
4. Ask the integrator to choose a supported production endpoint. Signing in does not itself change the endpoint’s embedding policy. [S1][S2]

For integration owners: change the endpoint deliberately

Two paths are operating a Jitsi server whose policy you control, or using JaaS. The IFrame API documentation explains how the meeting domain and API script are selected; use the corresponding provider’s authentication instructions. Our embedding guide covers the self-hosted setup. [S1][S5]

Recommended migration checklist:

• Inventory the meeting server in the plugin or application, not just the address of the outer page.
• Update the meeting domain and the matching API script source. Check hard-coded defaults and fallback URLs too. [S5]
• Preserve the intended host/guest access policy. A different server can require different authentication. Follow the JWT guide where applicable.
• Validate HTTPS, framing permissions, login and a complete meeting. A loaded iframe is not proof that the full integration works. See integration diagnostics.
• Test beyond the former cutoff, then verify joining, leaving and bidirectional audio/video with independent participants.

Changing a client display option is not a supported way to override another operator’s service policy. [S1][S2]

If it happens on your own server

The optional mod_time_restricted Prosody module in the pinned 11248 source defaults conference_max_minutes to 5 when enabled without an explicit value. Its conference_grace_seconds default is 0. Inspect whether the module is enabled on the main conference component before assuming an embedding restriction. [S4]

For Docker, review the active release, your normal Compose environment and the generated Prosody configuration. For Debian/Ubuntu packages, inspect the installed conference-component configuration. The administrator section of our time-limit guide explains the relevant settings. Preserve existing modules and access policy; apply any intended change through your normal maintenance process. [S4]

Also check whether your own client deployment disables embedding. The same reviewed client mechanism can apply to a privately hosted deployment; a custom domain does not automatically prove embedding is enabled. [S2]

Verify the result

Use a disposable test meeting and record the exact server, client version, embedding context, warning and elapsed time. Confirm which fix you changed: embedding endpoint, room-duration policy or authentication. Then run past the original failure point and verify audio/video in both directions. Keep invitation links and raw diagnostic logs private.

If the call still drops without a policy warning, continue with connection diagnostics instead of repeatedly increasing a timer.

Open questions and maintenance

Reviewed 24 October 2026 against Jitsi Meet 11248 source commit f765042. These are source-reviewed diagnostic steps, not a reproduced five-minute production call. A request from our research client to meet.jit.si/config.js returned HTTP 403, so we did not verify its current configuration value. That request result does not establish what normal participant browsers receive.

Recheck the official service policy and installed client code when either changes. Native apps, custom SDKs and provider-specific deployments need their own version check; the source condition is not proof that every client hits it. [S1][S2]

Sources

• [S1] Jitsi’s official embedding service guidance, reviewed 24 October 2026. Use it for service policy; some generic API examples still show the public endpoint.
• [S2] Pinned 11248 embedding timer constant and conditional client behavior.
• [S3] Official 95-minute meet.jit.si announcement, 9 October 2026.
• [S4] Pinned server-side time-restriction module, optional enablement and duration defaults.
• [S5] Official IFrame API integration reference, API domain and script selection. Service policy is documented separately in [S1].