v2.7 Runbook

High Database Load in MailWizz

Inspect campaign queries, bounce processing, cron overlap, table growth and missing maintenance.

Trigger

Use this runbook when the condition is persistent, affects a measurable scope, and differs materially from the established baseline.

Immediate protection

  1. Identify affected providers, source IPs, domains, customers and campaigns.
  2. Pause or reduce only the affected stream when evidence justifies containment.
  3. Preserve logs, queue snapshots, DNS answers and recent configuration versions.
  4. Record the start time and the first known abnormal signal.

Evidence to collect

  • Exact SMTP replies and enhanced status codes.
  • Queue depth and oldest-message age by provider.
  • Traffic and acceptance rates before and after the change.
  • Recent DNS, application, MTA and infrastructure changes.
  • Host resource and service-state evidence.

Decision path

  1. If one provider is affected, inspect provider responses and stream-specific reputation.
  2. If all providers are affected, inspect DNS, host resources, routing, TLS and application submission.
  3. If one customer or campaign is affected, isolate data quality, content, identity and traffic changes.
  4. If evidence begins immediately after a release, compare configuration versions and prepare rollback.

Recovery validation

Recovery requires stable acceptance, declining queue age, normal resource use and no recurrence across at least two monitoring intervals. Do not declare recovery based on a single successful test message.

Record the outcome: Add the confirmed cause, containment action, recovery evidence and prevention task to the incident timeline.

Build an incident timeline · Download evidence checklist

Search Trushilla Documentation