Skip to content

Troubleshooting

Common issues and what causes them. Everything below is drawn from the plugin's own notes and recommendations.

Sessions cut off after 5 minutes

Symptom: conferences end abruptly after about five minutes.

Cause: the plugin connects by default to the public server at meet.jit.si, which restricts embed mode to 5 minutes per conference.

Fix: meet.jit.si is only suitable for quick testing. For production use one of the real server options — a GCP auto-managed server, a JaaS (8x8) account (free up to 25 monthly active users), or a self-hosted Jitsi server.

Everyone joins as a moderator (self-hosted JWT)

Symptom: on a self-hosted server, all users can mute or remove others — the Moodle role is ignored.

Cause: the moderator field in the JWT token is being ignored because the required Prosody plugin is missing.

Fix: install the jitsi-token-moderation-plugin on your self-hosted Jitsi server (type 1). It is not needed on 8x8 JaaS or GCP auto-managed servers. See JWT / token mode.

Moderation restrictions can be bypassed (no token mode)

Symptom: experienced users get around mute everyone / kick out participant even though those buttons are hidden for them.

Cause: without token configuration, moderation is only hidden in the interface, not enforced on the server.

Fix: deploy a server in token-based mode so only users with the mod/jitsi:moderation capability are actual moderators. See JWT / token mode.

Reporting and analytics features are missing

Symptom: the attendance report, recording view tracking, viewing heatmap, course overview or session usage statistics do not appear.

Cause: these features require a registered mod_jitsi Account.

Fix: register your installation from Site administration → Plugins → Activity modules → Jitsi (the mod_jitsi Account section at the top). Registration is free.

Live-session attendance data is empty

For the live sessions tab, the aggregate_usage_stats scheduled task must have run at least once — the data is pre-computed nightly. New sessions will not show exact connection times until that cron task runs.

Symptom: a JaaS cloud recording's Download button no longer works.

Cause: JaaS (8x8) cloud recording links are hosted on 8x8's CDN and expire after 24 hours (or according to your JaaS plan).

Fix: this is expected. Once expired, the links are automatically hidden from the Recordings tab — no manual cleanup is needed.

Symptom: after a Dropbox recording stops, no link shows up in the Recordings tab.

Cause: Jitsi fires recordingStatusChanged when the recording stops, but the Dropbox URL is generated asynchronously by Dropbox after the upload completes, so it is not included in the event. Dropbox links therefore cannot be captured automatically.

Fix: the teacher must publish the link manually — get the share link from Dropbox and paste it into the Add recording link form in the activity's Recordings tab.

Embedded Dropbox video stops playing for some students

Symptom: an embedded Dropbox recording becomes unavailable when many students watch at once.

Cause: Dropbox enforces a monthly bandwidth limit on free accounts, and may temporarily block direct access when many students view the embedded video simultaneously.

Fix: this is a Dropbox limitation. A fallback Open recording link is always shown below the embedded player.

YouTube authorisation keeps expiring

Symptom: corporate YouTube recording/streaming stops working and asks for re-authorisation every few days.

Cause: when the Google OAuth app is in "Testing" status, only explicitly added accounts can authorise it and tokens expire every 7 days.

Fix: either publish the OAuth app, or — if your institution uses Google Workspace — set the OAuth consent screen "User type" to INTERNAL, where tokens never expire.

Never delete the OAuth credentials

Deleting the OAuth credentials in Google Cloud will remove all recordings from the associated YouTube accounts.

Browser shows SSL warnings on a GCP auto-managed server

Symptom: users see certificate warnings when joining a freshly created GCP server.

Cause: if DNS was not yet propagated when the VM finished installing, the startup script falls back to a self-signed certificate instead of a Let's Encrypt one. Without proper DNS, JWT authentication may also misbehave.

Fix: create the required A records immediately when the static IP is shown — both your-hostname and auth.your-hostname pointing to the same IP — so Let's Encrypt can issue a valid certificate. See GCP setup.