The SLA You Never Negotiated
Every organization that adopts an open-source framework enters an implicit service-level agreement. When a bug is reported, how long does it take to get attention? When a security issue surfaces, how many days pass before a fix is merged? These timelines are measurable. WebPulse tracks issue close times and PR merge times across every framework in its index. The spread is enormous.
The Fastest Responders
Astro closes issues in an average of 19.0 days. Astro merges pull requests in an average of 0.3 days — less than 8 hours from submission to merge. Next.js merges PRs in 0.5 days. These are not aspirational targets. They are measured averages across the full history of each repository. For organizations running Astro or Next.js in production, a reported issue enters a pipeline that processes it in days, not months.
The speed is a function of organizational investment. Astro has 335 contributors and made 2,913 commits in the past year. Next.js has 427 contributors and made 5,709 commits. The contributor density that drives commit velocity also drives issue responsiveness — the same people who write features also triage bugs.
The Middle Tier
Joomla closes issues in 60.1 days and merges PRs in 1.2 days. Nuxt closes issues in 60.4 days and merges PRs in 3.8 days. These are workable timelines for most organizations — a two-month window for issue resolution, with PRs reviewed and merged within a business week. Not fast, but not a governance gap.
The distinction between the middle tier and the top tier matters most for security issues. A vulnerability disclosed against Nuxt sits in the open for roughly 60 days on average before resolution. The same vulnerability disclosed against Next.js is addressed in a fraction of that time. For organizations in regulated industries — healthcare, finance, government — the difference between 60 days and 19 days of exposure is the difference between compliance and audit finding.
The 273-Day Tail
Gatsby takes 273.6 days — nine months — to close an average issue. Gatsby merges PRs in 4.4 days, which suggests the team responds to contributed fixes but lacks capacity to address the backlog of reported issues internally. With 179 commits in the past year and an activity score of 40.0, Gatsby's issue queue is growing faster than its team resolves it.
For the organizations running Gatsby in production, 273.6 days is the expected timeline for any reported problem. A security vulnerability, a breaking change in a dependency, a performance regression — each one enters a queue with a nine-month average resolution time. That is not a framework limitation. It is an operational risk that compounds with every issue filed.
Response Time as a Selection Criterion
Framework selection processes typically evaluate feature sets, performance benchmarks, and ecosystem size. Response time rarely appears in the evaluation matrix. The data argues it should be weighted heavily. A framework that takes 19 days to close issues (Astro) versus one that takes 273 days (Gatsby) delivers a 14x difference in responsiveness. That multiplier applies to every bug, every security patch, every compatibility fix your production deployment depends on.
Your framework's response time is your response time. When a zero-day drops against a dependency your framework shares, the clock starts. The framework team's average close time is the floor of your remediation timeline. At 273.6 days, that floor is nine months. At 19.0 days, it is three weeks. The gap is not a technical curiosity — it is the operational risk embedded in your technology choice.
