Repository navigation
[FEATURE] [Datadog] Track FFmpeg.wasm load performance and export success/failure via RUM, with a public status page #1788
Description
Activity
👋 Thanks for opening an issue, @magic-peach!
Our maintainers will review this shortly 🚀
Before you start working
- 📖 Read the CONTRIBUTING.md guide
- 💬 Wait for a maintainer to assign you the issue before starting work
- 🔍 Search for existing issues to avoid duplicates
For GSSoC'26 contributors
If you're contributing under GirlScript Summer of Code 2026, please mention it in your comment when requesting assignment:
"I'd like to work on this — contributing under GSSoC'26"
Architecture notes
Reframe is a static Next.js app with
output: "export". Key points:- All video processing uses FFmpeg.wasm (client-side, no server)
headers()innext.config.tswon't work — usevercel.jsoninsteadnot-found.tsxrequirespublic/404.html+vercel.jsonroutes config
Happy contributing! ⭐ Star the repo if you find it useful!
- added a commit that references this issue
on Oct 1, 2026 - added a commit that references this issue
on Oct 3, 2026
Feature description
Datadog RUM is now integrated (
src/components/DatadogInit.tsx, sessionSampleRate 100, sessionReplaySampleRate 0) but only does the SDK's automatic page-view/error tracking — it doesn't instrument anything Reframe-specific yet.Problem this solves
There's currently no visibility into real-world FFmpeg.wasm engine load times (how long does that ~30MB download actually take for real users on real connections?) or export success/failure rates in production — exactly the kind of thing that would validate or invalidate ideas like issue #181's caching proposal or #14 above.
Proposed solution
Add custom RUM actions/timings around
loadFFmpeg()(engine load duration) and around export start/success/failure (useVideoEditor.ts's export flow) viadatadogRum.addAction/addTiming. Eventually surface this as a small public status/performance page (even a simple one built from a scheduled export of Datadog's aggregated metrics).Alternatives considered
Could scope the "public status page" part as a separate follow-up issue once the instrumentation itself lands — the instrumentation is the higher-value, more scoped first step.