Why Reelium stays up
You are trusting a small team with the footage from your stream. That is a fair thing to be careful about, so here is how the pipeline is actually built — and where to check it for yourself.
Rendering is decoupled from the website
Clips render on AWS Lambda through Remotion, not on the machine serving this page. A traffic spike on the site cannot slow your render, and a render that fails cannot take the site down with it. The two scale independently because they are genuinely separate systems.
The video fetcher is isolated too
Pulling source video from Twitch is the slowest and least predictable step in the pipeline, so it runs as its own service rather than inside the app. When a platform changes something and downloads get difficult, the blast radius is one subsystem — and you can see its state on the status page.
Stuck work gets swept, not forgotten
Scheduled jobs run continuously to catch analyses, renders and publishes that stalled, and to keep the render service warm so the first request after a quiet period doesn't time out. Recovery is routine and automatic rather than something that waits for someone to notice.
We publish the record, including the gaps
The status page checks the database, the render worker and the service configuration, and keeps a 30-day history. Days we did not measure show as "no data" rather than green — if our own monitoring was down, the grid says so instead of quietly filling in a clean bill of health.
What we don't claim
Reelium is not a five-nines operation and we are not going to print a number that suggests otherwise. Twitch changes things, AWS has bad days, and so do we. What we will do is show you the real record, keep the failure of one subsystem from becoming the failure of all of them, and make sure that when something breaks it breaks somewhere recoverable.
Something looks wrong and the status page says otherwise? Email support@reelium.ai.