Jitsi recording not working: Jibri errors and fixes

Start with the logs. Jibri is chatty and usually says exactly what went wrong:

docker compose -f docker-compose.yml -f jibri.yml logs --tail 200 jibri

Then match what you see.

“Timed out waiting for call page to load”

Jibri opens the meeting in headless Chrome. This error means the page never finished loading.

Cause A: an untrusted certificate. On a server reached by IP, the stack serves a self-signed certificate. A human can click through the warning; Jibri cannot. We saw every recording fail this way on IP-only test servers. Fix it with a real domain and certificate, or for IP-only servers set this in .env and recreate Jibri:

IGNORE_CERTIFICATE_ERRORS=1

Cause B: the recorder cannot reach the public URL. A dedicated recorder must resolve and reach PUBLIC_URL on 443. Test from the recorder: curl -I https://meet.example.com.

Recording starts, then stops, or has no audio

Jibri captures audio from the ALSA loopback device.

lsmod | grep snd_aloop || echo "snd-aloop not loaded"
sudo modprobe -n snd-aloop && echo available || echo missing

On AWS, Ubuntu’s linux-aws kernel does not include snd-aloop at all. Install linux-generic, make it the GRUB default and reboot once. Steps are in Jitsi on AWS.

With several Jibri instances, give the module enough devices and substreams:

echo "options snd-aloop enable=1,1,1 index=0,1,2 pcm_substreams=8" | sudo tee /etc/modprobe.d/jibri-aloop.conf

The Record button does nothing, or “Recording unavailable”

No idle Jibri. One Jibri records one meeting. If another meeting is recording, the next request has nobody to take it. Scale up the number of Jibri instances.

The recorder cannot log in. In the Jibri logs, look for authentication errors. These values must be identical on the Jitsi server and every recorder:

• XMPP_RECORDER_DOMAIN
• JIBRI_RECORDER_PASSWORD
• JIBRI_XMPP_PASSWORD

We pin XMPP_RECORDER_DOMAIN explicitly on both sides. Relying on each side’s default is how a mismatch sneaks in after an upgrade.

A dedicated recorder cannot reach Prosody. It needs 5222/tcp on the Jitsi server. Allow it only from the recorder (on AWS, from the recorder’s security group) and confirm the Prosody container publishes the port. A recorder that retries “Error connecting” forever is almost always this.

Recordings never reach S3

If you upload with a finalize script and a timer:

• The finalize script must be executable and at the path in JIBRI_FINALIZE_RECORDING_SCRIPT_PATH.
• The host must have credentials: on AWS an instance profile with s3:PutObject on the bucket.
• Check the uploader’s own logs with journalctl -u recording-upload.

The server struggles while recording

Each recording keeps about two CPU cores busy with Chrome and ffmpeg. On a small shared server, meetings get choppy during recording. Move Jibri to its own server (a c5.large per concurrent recording is a good start on AWS).

Want it working today?

Send us your Jibri logs and we will fix it, or see our recording setup service. On our one-click platform, recording is a tested $39 add-on that handles all of the above.