Emergency Production Hotfix Access for Metricfixer Support

Use this guide when Metricfixer must work on an urgent live production issue and the normal staging-first workflow is not enough. Emergency production hotfix access should be temporary, controlled, documented, and limited to the exact repair needed to restore or protect the live system.

When to use this guide

This guide applies when a live production system is broken, degraded, or at risk and waiting for the full standard workflow may cause unacceptable business impact.

Typical examples include:

• the website, store, application, checkout, payment flow, login, lead form, or booking flow is down or failing in production;
• a recent deploy, plugin update, theme update, CMS change, tag change, server change, DNS change, or configuration change broke live functionality;
• critical tracking, conversion collection, ecommerce measurement, or advertising attribution is broken and must be restored quickly;
• a production deploy is stuck, partially applied, or causing errors that need a controlled rollback or hotfix;
• a database migration, cache change, queue worker, cron job, webhook, API integration, CDN, SSL/TLS, DNS, or server configuration caused a live incident;
• the client has no staging environment, or staging cannot reproduce the urgent production issue in time.

What emergency mode means

Emergency mode means Metricfixer may work directly with production systems after your explicit approval. It does not mean unrestricted access, broad refactoring, feature development, redesign, performance optimization, or unrelated cleanup.

The goal of an emergency hotfix is narrow:

• identify the production-breaking cause;
• restore the affected live function or reduce the active damage;
• make the smallest safe change required;
• document what changed;
• prepare or preserve a rollback path;
• move the final change back into the repository or normal deployment workflow after the emergency is resolved.

Before Metricfixer starts

Please add the following confirmation to the ticket:

I confirm emergency production hotfix mode for this ticket. I am authorized to approve production changes for this project. I understand that production changes may affect live users, orders, payments, data, analytics, advertising, SEO, email delivery, and other business-critical systems. I confirm the backup and rollback information provided in this ticket.

Information to provide in the ticket

To start quickly and safely, please provide as much of the following as possible:

• production URL, affected page, affected flow, affected account, or affected environment;
• what is broken, when it started, and what changed shortly before the problem appeared;
• screenshots, screen recordings, error messages, failed order IDs, affected event names, failed workflow links, or monitoring alerts;
• steps to reproduce the production problem;
• last known good deploy, commit, release, backup, plugin/theme version, container image, configuration state, or timestamp;
• current deploy method: GitHub Actions, hosting panel, SSH, SFTP, FTP, Shopify theme, WordPress admin, cloud console, CI/CD, Docker, or manual upload;
• repository URL and production branch, if code is involved;
• staging URL, preview deployment, or test environment, if available;
• logs or access to logs: application logs, server logs, hosting logs, CDN logs, browser console errors, payment logs, webhook logs, or tag/debug output;
• backup status: files, database, theme, container, deployment release, cloud snapshot, GTM container, DNS zone, or relevant platform export;
• rollback method: restore backup, revert commit, redeploy previous release, switch theme, disable plugin, restore container image, roll back migration, restore DNS/CDN settings, or apply a prepared patch;
• authorized approver name and email;
• preferred maintenance window and timezone, if the change may interrupt live use.

Minimum safe access to provide

Provide the narrowest access that allows Metricfixer to diagnose and repair the urgent issue. The exact access depends on your stack.

GitHub and deployment pipeline

• Give Metricfixer Write access to the repository when code changes are required.
• Keep main, master, or the production branch protected where possible.
• Allow Metricfixer to create an emergency branch and pull request, even if the review is expedited.
• Use a production deployment environment with required approval when available.
• Do not give organization owner access, repository admin access, billing access, or access to unrelated repositories unless the task explicitly requires it.

Server, SSH, SFTP, or hosting

• Create a temporary user such as metricfixer-hotfix or metricfixer-deploy.
• Prefer SSH key access over password access.
• Limit access to the affected project directory, release directory, staging directory, or log directory.
• Avoid root access and unrestricted sudo. If privileged commands are required, allow only the specific deploy, restart, log, rollback, or service command needed for the approved repair.
• For SFTP/FTP-only hosts, restrict the account to the affected website directory and confirm the latest backup before changes.
• Do not provide hosting master accounts, billing access, registrar owner access, email admin access, or access to unrelated websites.

Database

• Start with read-only production database access if the task only requires diagnosis.
• Use staging or a sanitized dump for deeper investigation where possible.
• Production database write access is exceptional and requires explicit approval in the ticket.
• Before any production write, migration, cleanup, import, or SQL patch, confirm a current database backup and a rollback option.
• Do not provide database root credentials, unrestricted admin access, unnecessary full production dumps, or unrelated customer records.

CMS, ecommerce, and platform access

• For WordPress or WooCommerce, create a temporary admin user only if the fix requires admin access. If file access is enough, use restricted SFTP or GitHub instead.
• For Shopify, prefer collaborator access, a duplicate theme, a theme preview, or theme-only access before live theme publication.
• For tracking and analytics issues, provide only the relevant GA4, GTM, Google Ads, Meta, TikTok, LinkedIn, Microsoft Ads, consent platform, CRM, or server-side tracking access.
• Do not provide payment gateway owner access, payout settings, staff management, store owner credentials, or live payment secrets unless the emergency task specifically requires them.

Cloud infrastructure

• Start with read-only logs, deployment events, metrics, and resource configuration when possible.
• For implementation, use a temporary role limited to the affected service, resource group, project, account, namespace, domain, or deployment pipeline.
• Prefer deployment pipelines, short-lived roles, workload identity, or OIDC-based deployment access instead of long-lived cloud keys.
• Do not provide cloud root accounts, organization owner roles, unrestricted IAM, billing roles, all-secrets access, or access to unrelated projects.

Production secrets and credentials

Please do not send production secrets through ordinary email, chat, or GitHub comments. This includes:

• .env files;
• database passwords;
• SSH private keys;
• cloud access keys;
• service account JSON keys;
• API secrets;
• payment provider secret keys;
• SMTP passwords;
• OAuth client secrets;
• recovery codes or backup codes.

If a secret is truly required, Metricfixer will ask for a secure method and the secret should be temporary, limited, and rotated after the task.

Backup and rollback requirements

Emergency production work should not begin until the backup and rollback status is clear. Depending on the affected system, this may include:

• website files backup;
• database backup or point-in-time restore option;
• hosting snapshot or cloud snapshot;
• previous deployment release or container image;
• previous Git commit or tag;
• WordPress theme/plugin backup;
• Shopify duplicate theme or previous theme version;
• GTM container export;
• server-side GTM container export;
• DNS zone export or record list;
• CDN/WAF configuration export;
• payment, webhook, or integration configuration notes.

Change freeze during the emergency

To avoid conflicts and data loss, please pause unrelated changes while Metricfixer works on the hotfix.

• Do not deploy unrelated code while the emergency ticket is active.
• Do not update CMS core, themes, plugins, apps, containers, packages, or server components unless agreed in the ticket.
• Do not change GTM, GA4, ad platform, consent, payment, DNS, CDN, or server settings in parallel unless coordinated.
• Do not ask another developer or agency to modify the same area at the same time without telling Metricfixer.
• Keep all emergency communication in the ticket so there is one source of truth.

What Metricfixer may do during an emergency hotfix

Depending on the approved scope and access, Metricfixer may:

• inspect logs, error output, deployment history, monitoring alerts, and recent changes;
• create an emergency branch, patch, commit, or pull request;
• apply a small production code patch when a pipeline-based fix is not possible in time;
• disable or revert a recently introduced breaking change;
• restart a service, queue worker, scheduler, container, PHP-FPM, web server, or application process if approved;
• clear or rebuild cache when required for the approved fix;
• restore a previous release, theme, container image, or configuration if approved;
• apply a reviewed SQL patch or migration only with explicit approval and backup confirmation;
• adjust configuration, environment variables, webhook URLs, tags, triggers, consent settings, or tracking settings when required for the incident;
• run smoke checks after the fix.

What Metricfixer will not do by default

• perform broad refactoring, redesign, feature development, SEO rewrite, or performance optimization under emergency hotfix scope;
• make destructive production database changes without explicit approval and backup confirmation;
• run commands that wipe, reset, truncate, or recreate production data unless this is specifically approved and backed up;
• accept unrelated full admin, billing, owner, or root access when a narrower method is available;
• store production secrets in the repository, Codex environment, public comments, ordinary email, or unprotected notes;
• make changes to unrelated systems, accounts, projects, properties, stores, campaigns, or environments;
• guarantee business performance, revenue recovery, advertising approval, or exact analytics recovery after the technical repair.

Emergency hotfix workflow

1. Incident confirmation: you confirm emergency mode, affected production system, business impact, and authorized approver.
2. Access review: Metricfixer confirms which minimum access is needed and rejects unnecessary secrets or excessive access where possible.
3. Backup and rollback check: files, database, configuration, container, theme, or platform rollback options are confirmed.
4. Diagnosis: Metricfixer checks logs, recent changes, deploy history, code, configuration, tracking, or platform state.
5. Fix plan: Metricfixer proposes the smallest practical change, rollback path, and expected impact.
6. Approval: you approve the production change in the ticket, or the emergency approval already given is confirmed as covering the specific fix.
7. Implementation: Metricfixer applies the approved change using GitHub, deployment pipeline, SSH/SFTP, CMS, cloud console, or platform access.
8. Smoke test: the affected flow is tested after the fix.
9. Documentation: Metricfixer records what changed, where it changed, and how to roll it back where possible.
10. Cleanup: access is revoked or reduced, temporary credentials are deleted or rotated, and direct production changes are moved back into the repository or normal deployment workflow.

After the hotfix is completed

Please complete the following cleanup steps:

1. Review the ticket summary and confirm whether the affected production flow works for you.
2. Revoke temporary users, SSH keys, SFTP accounts, CMS users, collaborator access, cloud roles, API tokens, and database users that are no longer needed.
3. Rotate any temporary secret, password, token, service account key, or private key that was exposed during the emergency.
4. Merge or archive the emergency branch, patch, or pull request according to your repository workflow.
5. Apply the same fix to staging if production was patched directly first.
6. Update your deployment notes, incident log, runbook, or monitoring alerts if the issue may recur.
7. Plan a non-emergency follow-up ticket for root-cause cleanup, tests, staging setup, CI/CD hardening, or refactoring if needed.

If you cannot provide external production access

Metricfixer can work in client-executed emergency mode. In that case, your team keeps production access and Metricfixer provides analysis, patches, commands, SQL scripts, rollback notes, or step-by-step instructions for your team to execute. Please send back command output, logs, screenshots, and test results after each step.

Related guides

• General Access Sharing Rules
• GitHub Access
• Server / SSH Access
• Database Access
• Cloud Infrastructure Access
• Revoke Access After Completion