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 jibriThen 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=1Cause 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 missingOn 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.confThe Record button does nothing, or “Recording unavailable”
If the control is missing only in a mobile app or SDK, start with the mobile recording checklist. It distinguishes client flags and version-specific permission handling from a Jibri failure. That checklist is source-reviewed, without a completed mobile recording test.
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_DOMAINJIBRI_RECORDER_PASSWORDJIBRI_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:PutObjecton 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.