Browser Extension Support: From Diagnostics to Staged Rollout

After a Chrome update, your browser extension stopped working? The target site changed its DOM, breaking data collection? We encounter this regularly. Without planned maintenance, an extension degrades quickly: new browser versions break APIs, sites change structure, and users switch to competitors. Our experience—5+ years and 50+ projects—lets us keep your extension running smoothly at every stage of its lifecycle. We offer a full support cycle for browser extensions: from diagnostics to staged rollout, with error monitoring and stability guarantees. Even if your extension hasn't migrated to Manifest V3 yet, we help you do it smoothly without losing users. If it's already on MV3, we set up monitoring and automatic updates. Every update stresses the ecosystem; we minimize it with phased releases and automation. Staged rollout reduces the risk of mass failures by 5x compared to instant releases.

What Problems We Solve

• Manifest V3 compatibility. This migration is mandatory for Chrome, and delaying is risky. Service workers, Declarative Net Request, fetch() instead of XMLHttpRequest—every detail matters. See more in Chrome documentation and MDN.
• Changes in target site DOM. If your extension parses data, any redesign breaks the logic. We use adaptive selectors and monitor for changes.
• Production errors. Even after thorough testing, bugs slip through. Our telemetry stack—Sentry plus our own endpoint—catches them instantly.

How We Do It: A Case Study of MV2 to MV3 Migration

One client, a trading automation service, had an extension on MV2 with a background page, webRequestBlocking, and inline scripts. Chrome warned about blocking within months. We completed the migration in two weeks:

1. Rewrote the background as an asynchronous service worker, separating logic into modules.
2. Replaced webRequestBlocking with Declarative Net Request—this required reworking the blocking rules.
3. Moved all inline scripts to separate files.
4. Tested with Playwright using a real profile, covering 100+ scenarios.
5. Rolled out staged: 1% → 10% → 50% → 100%.

Result: the extension runs on MV3 with zero failures, CPU load dropped by 30%. Staged rollout reduces the risk of mass failures by 5x compared to instant releases. Our automated testing is 3 times faster than manual testing and catches 90% of issues before release.

When Should You Update to MV3?

If your extension is still on Manifest V2, Chrome will eventually block it. We recommend starting the migration at least six months before the deadline. The process takes from two weeks, but may take longer if the code heavily depends on the background page. Plan ahead—your users won't notice the transition. Our support plans start at $500 for a planned update, with full MV3 migration from $2,000.

Our Work Process

1. Analysis. Audit of current code, identification of bottlenecks, alignment on the plan.
2. Design. Update architecture, choice of observability tools.
3. Implementation. Fixes, migrations, new features.
4. Testing. Automated (Playwright) + manual in different browsers.
5. Deployment. Staged rollout via Chrome Web Store, publication for Firefox.
6. Support. Error monitoring, response to feedback, planned updates.

What's Included in Our Work

• Full diagnostics and report on extension status.
• Migration to current API versions (MV3, new browser APIs).
• Integration of error monitoring system (Sentry, custom endpoint).
• Setup of staged rollout for safe updates.
• Adaptation for Firefox, Edge (with polyfill if needed).
• Documentation on the update process and emergency contacts.

How Migration from Manifest V2 to V3 Works

This is not just changing fields in manifest.json. Key steps:

1. Service Worker replaces background page. Move event listeners, message handlers.
2. Replace XMLHttpRequest with fetch(). Service workers in MV3 have no access to XHR.
3. Move from webRequestBlocking to Declarative Net Request. Request blocking becomes declarative—no ability to modify responses.
4. Extract inline scripts. All scripts must be separate files.
5. Testing. Playwright with --load-extension checks every scenario.

Why Testing Before Update Matters

A single error can block hundreds of users. Automated tests in Playwright emulate real scenarios: login, popup interaction, data collection. We also use fetch() to send errors to Sentry—even if the extension crashes, we know first. This approach saves up to 40% of debugging time. Our observability stack provides 99.9% visibility into runtime behavior.

Browser API Comparison

Support Timelines

Pricing is determined individually after analysis. Request a planned update—we'll assess the scope and suggest an optimal plan. Our browser extension support ensures smooth operation across all platforms.

Tools We Use

• Playwright for end-to-end extension testing.
• Sentry + custom endpoint for error collection.
• web-ext for signing the Firefox version.
• webextension-polyfill for unifying Chrome/Firefox API.

Test automation and staged rollout significantly cut support costs. Contact us—we'll ensure your extension has a long life without surprises. Get a consultation for your extension today.

Website Technical Support: Updates, Monitoring, SLA

A website on Laravel 8 with PHP 7.4. PHP 7.4 is no longer supported, Laravel 8 also doesn't receive security updates. The hosting provider warned about the mandatory PHP update to 8.1 — after the update, two plugins and one library broke, the site went down. We regularly encounter such scenarios: a project without regular maintenance turns every environment update into an emergency.

This case is not an exception, but a rule. Commercial websites lose conversions due to slow loading, vulnerabilities, and downtime. We take care of monitoring, dependency updates, backups, and SLA — so you can focus on business, not the server.

Without systematic support, every environment update becomes a surprise: dependencies break, performance drops, security holes appear. Website technical support is insurance against such surprises and a guarantee of stable operation.

What Actually Goes into Website Technical Support?

Support is not "answering a call when something breaks." It is systematic prevention of breakdowns.

Dependency updates. Composer packages, npm packages, CMS or framework. composer audit and npm audit show known vulnerabilities. Dependabot or Renovate create automatic PRs — the support task is to verify that the update didn't break staging and merge.

Updates types: patch (1.2.3 → 1.2.4, only bugfix, safe), minor (1.2.0 → 1.3.0, new features with backward compatibility, usually safe), major (1.x → 2.x, breaking changes, require testing). Ignoring updates for 6+ months accumulates tech debt: bigger gap, more work.

WordPress is a separate story. The platform's popularity makes it a prime attack target. Outdated plugins are the #1 attack vector. Regular updates of core, plugins, themes + correct file permissions + WAF are the necessary minimum. Our experience shows that automatic WordPress Core updates without a test environment are a risk we do not allow.

How Does Monitoring Prevent Downtime?

Uptime monitoring. Basic HTTP check every minute. Better Uptime, Upptime (self-hosted), Checkly, New Relic Synthetics. Alert to Telegram or Slack on downtime — and notification upon recovery. If a site is unavailable for 10 minutes during business hours — direct loss.

Performance. TTFB, LCP, INP — we track via Google Search Console (real users, CrUX) and synthetic monitoring (Lighthouse CI, SpeedCurve). Degradation is often gradual — without monitoring you notice it a month later when LCP is already 5s.

Application errors. Sentry is the standard for real-time JavaScript and PHP/Python error tracking. Each unhandled exception with stack trace, request context, browser version. Especially important for errors users don't report — they just leave.

Database. Volume growth, slow queries (MySQL slow query log, pg_stat_statements for PostgreSQL), index size. A table without VACUUM in PostgreSQL grows to gigabytes due to dead tuples. Routine database maintenance is part of support.

Disk space and logs. Is logrotate configured? /var/log/nginx growing without limits and filling the disk — classic. Automatic rotation + alert at disk > 80%.

Why Are Backups Without Verification an Illusion?

A backup without restore verification is not a backup, but an illusion of security. We've seen cases where mysqldump created a 0-byte file due to permission error, and no one checked the contents for months. We guarantee all copies are restorable.

Backup scheme:

• Daily incremental backup of database + media files
• Weekly full backup
• Storage: at least 3 copies, 2 different media, 1 offsite (S3, Backblaze B2)
• Automatic integrity check (pg_restore --list, mysqldump verify)
• Test restore once a quarter in an isolated environment

Retention policy: 7 daily, 4 weekly, 3 monthly. S3 Lifecycle rules automate deletion.

SLA: What Does It Mean in Practice?

SLA (Service-Level Agreement) Wikipedia — specific commitments for response and resolution times:

SLA makes sense only with monitoring — otherwise you learn about problems from users, not systems. A broken button in a form can silently kill conversions for weeks.

Content Update Process

A developer should not be in the chain for editing text on a page. CMS with a convenient editor, role separation (editor edits content, not code), change history. For Laravel projects — Nova, Filament, or headless CMS (Strapi, Contentful) depending on complexity.

Preview before publishing, staged rollout for important changes. If editors work directly on prod — that's a risk.

Typical Situations We Resolve

Website hack: attack vector analysis, cleanup, security hardening (WAF, fail2ban, file permission restrictions). Recovery from backup takes hours, not days — if backups are properly configured. Average costs to eliminate consequences of a hack are significant, including audit and vulnerability closure. Regular support is much cheaper and prevents such incidents.

Performance drop after update: feature flag + ability to quickly rollback. Canary deployment — update 5% of traffic, check metrics, then 100%.

What's Included in the Support Package (Deliverables)

Upon signing the contract, you receive:

• Documentation: infrastructure diagram, access, recovery procedures
• Monitoring: uptime, performance, errors, logs — set up from day one
• Backup: daily/weekly copies with verification
• Dependency updates: monthly audit and update with testing
• SLA response: per priorities from the table above
• Reports: weekly dashboards, monthly review, quarterly tech plan
• Content editing support: editor training, permission setup

Contact us to choose a suitable plan and get an initial audit of your project.

How We Work: Stages

1. Onboarding (3–5 days): audit of current state, setup of monitoring and backups, infrastructure documentation.
2. Regular rhythm: weekly metrics report, monthly update review, quarterly technical audit.
3. Response: per SLA, with recording of cause and resolution time.
4. Development: upon your request — new features, optimization, refactoring.

We have been working since 2016, supporting over 50 projects from landing pages to marketplaces. Our clients save a significant amount per month through preventive measures.

Timelines and Cost

Setting up monitoring and backups: 3–5 days. Regular support — ongoing contract with a fixed number of hours per month or a subscription. Cost is calculated individually after audit. Get a consultation — we will evaluate your project in 1–2 days.

Comparison: Monitoring with Automatic Alerting vs Manual Checking

Automatic monitoring with Better Uptime responds to failures 10 times faster than manual checking.