What we commit to, and what happens when it breaks.
MCT does not sit in the send path. Even during a full outage your existing emails still send. What pauses is producing new translations.
The numbers, and what they exclude.
Response time targets for tickets live on the support page. See severity levels and response times
When we touch production.
Sundays 02:00 to 04:00 CET when needed. Most releases ship with no downtime at all.
At least five business days for anything with expected downtime, by email to your registered admin contacts.
Security fixes may ship outside the window. We notify during or immediately after, with what changed and why.
You hear it from us first.
Timelines below are targets for a service wide incident, measured from the moment we confirm impact.
For a service wide outage, an initial notice goes to affected admin contacts confirming we are on it and what is affected.
Regular updates while the incident is open, even when the update is that there is nothing new.
Confirmation that service is restored and whether any translation jobs need to be re-run.
For P1 incidents, a written summary with cause, impact window and the prevention work. Sent to Growth and Enterprise customers on request.
If MCT is unavailable.
Translations already saved into Content Builder are ordinary SFMC assets. They live in your instance, they send from your instance, and they keep working whether or not MCT is reachable. There is no runtime dependency on us at send time.
Backend infrastructure is deployed so it can be rebuilt from configuration, and credentials live in a managed secret store rather than in code. If we ever wind the service down, you keep every asset MCT produced, with no export step and no lock in.
Full architecture and credential handling is documented on the security page. Read the security commitment
Need these numbers in a contract?
Enterprise order forms can commit availability, response times and post incident reviews in writing.
