Support & incident reporting
Last updated: 31 August 2026
CrossTenant is built and supported by a small team in the United Kingdom. That has one real advantage worth stating plainly: when you email support, you reach someone who can read the code and change it. There is no tier-one script in the way.
Where to send what
| What | Where | Target first response |
|---|---|---|
| Something is broken, or you need help using the console | support@crosstenant.com | By severity — see below |
| A security vulnerability in CrossTenant | security@crosstenant.com | 1 business day, acknowledged |
| A suspected compromise of your console or an operator account | security@crosstenant.com, subject line starting URGENT |
4 business hours |
| Data-protection requests, DPA questions, sub-processor objections | privacy@crosstenant.com | 2 business days; statutory deadlines met in full |
| Billing, contracts, and everything else | toby@crosstenant.com | 2 business days |
Business hours are 09:00–17:30 UK time, Monday to Friday, excluding England & Wales public holidays.
Severity and response targets
These are the targets we work to. They are commitments of effort and attention, not contractual service levels — the Terms of Service govern what is contractually owed, and an Order can agree something firmer.
| Severity | What it means | First response | Then |
|---|---|---|---|
| S1 — Critical | The console is unavailable, or an issue is actively causing incorrect changes to a managed Google Workspace tenant. | 4 business hours | Worked continuously during business hours until mitigated; you get an update at least daily. |
| S2 — High | A major feature is unusable and there is no reasonable workaround. Administration continues elsewhere. | 1 business day | Update at least every two business days until resolved. |
| S3 — Normal | A feature is degraded, wrong in a bounded way, or has a workaround. Includes most bugs. | 3 business days | Scheduled into the release queue with an indication of when. |
| S4 — Low | Cosmetic issues, questions, documentation, and feature requests. | 5 business days | Tracked; no commitment to a delivery date. |
What to include
A useful report gets a useful answer faster. Where you can, tell us: what you were doing and what happened instead; the affected customer organisation (its primary domain is enough); the approximate time, with a timezone; and the console URL you were on. Please do not send screenshots or exports containing your customers’ end-user personal data unless we specifically ask for them — we can almost always diagnose from the action and the error alone.
Reporting a security vulnerability
We welcome reports from security researchers and from customers’ own security teams. Email security@crosstenant.com with enough detail to reproduce the issue. Our machine-readable contact details are published at /.well-known/security.txt under RFC 9116.
What you can expect from us
- Acknowledgement within 1 business day.
- An initial assessment, including our severity view, within 5 business days.
- Progress updates at least every 10 business days until the issue is closed.
- Credit in the release note if you would like it, and no objection to you publishing once a fix is available and deployed.
Safe harbour
If you make a good-faith effort to comply with this policy during your research, we will treat it as authorised, will not pursue or support legal action against you in respect of it, and will help make clear that your actions were authorised if a third party raises them. Good faith means: testing only against your own instance or with our written permission; stopping as soon as you have demonstrated a vulnerability; not accessing, modifying, or exfiltrating anyone else’s data; not degrading the service; and giving us reasonable time to fix the issue before disclosing it.
Out of scope
Reports that are out of scope for us: findings against Google Workspace or Google’s APIs (report those to Google); findings against our sub-processors’ own infrastructure (report those to them — we are happy to help route it); volumetric denial-of-service testing; social engineering of anyone; physical security; missing security headers or best-practice recommendations on the marketing site with no demonstrated impact; and reports produced solely by an automated scanner with no validated exploit path.
Incidents, maintenance, and status
We do not run a third-party status page. For a service of this size a status page tends to be a decoration that lags the truth, so we commit to direct notification instead:
- Unplanned incidents affecting availability or correctness: we email the billing contact of every affected customer, with what is happening, what is affected, and what to do meanwhile. Updates follow at the cadence in the severity table until it is resolved.
- After an S1: a written summary within 5 business days — what happened, why, what we changed so it does not recur.
- Planned maintenance with expected disruption: at least 5 business days’ notice by email. Most changes deploy without downtime and are not announced individually.
- Personal-data breaches: notified without undue delay, and in any event within 72 hours of us becoming aware, per the DPA. That obligation is contractual and is not affected by anything on this page.
- Google-side outages: these show up as failing features but are not ours to fix. We will say so quickly and point you at Google Workspace Status rather than leave you guessing.
A note on access during support
We do not have standing access to your console or to your customers’ Google Workspace tenants. If diagnosing an issue needs us to see something directly, we will ask, we will agree the scope with you first, and the access ends when the investigation does. Everything we do through the console is recorded in the same tamper-evident audit log as everything you do — see the security page.