Contacts & runbook

When a site goes down, the clock is the enemy and the questions are always the same: who hosts it, who built it, who do we call, and what do we do first? The Contacts tab answers all four in advance. It keeps the key people for a site in one place, alongside an editable "if it goes down" runbook, so a crisis becomes a checklist instead of a scramble.

The contacts a site can have

Contacts are grouped by role, so an emergency guide reads cleanly. The types are:

• Developer / Designer - who built or maintains the site.
• Hosting Provider - where the site is hosted.
• Domain Registrar - where the domain is registered.
• Email Provider - who runs the mailboxes.
• Legal / Solicitor - for anything that needs legal input.
• IT Support / MSP - the client's own IT people, if any.
• PR / Communications - who handles public messaging if an incident goes public.

Each contact holds a name, phone, email, a URL and free-text notes, so you can capture a support portal link or an account number alongside the person.

A shared pool, assigned per site

Contacts are not re-typed for every website. They live in a shared pool for your organisation and are assigned to the sites that use them. That matters in practice:

• Enter your usual hosting provider once, then assign it to each site it hosts. Update the phone number in one place and every site sees the change.
• On a site you can assign an existing pooled contact, or create a new one and assign it in a single step.
• You can mark one contact per type as the primary, which is the one used as the headline contact on that site's emergency guide.
• Removing a contact from a site unassigns it there; it stays in the pool for other sites.

The "if it goes down" runbook

Alongside the contacts, each site has an editable runbook: your own first-response steps for that specific site, written as one step per line. It is free text, so you write it in whatever way suits the site, for example:

• Check the hosting status page before assuming it is your fault.
• Log in to the control panel (credential is in the vault) and check disk space.
• If DNS looks wrong, call the registrar on the number in Contacts.
• If it is a hack, isolate the site and follow the security guide.

The runbook is saved against the site and can be edited at any time. Because it lives on the same tab as the contacts, the person and the plan are never more than a glance apart.

Printable emergency guides

From the Contacts tab you can download the site's details as a PDF, so the plan exists even if TLDTrack is not the thing you can reach in the moment:

• An emergency staff guide, pulling together the primary contacts, the runbook steps, and quick facts like how many days are left on the SSL certificate and the domain registration.
• An "if hacked" security-incident guide, laying out who to contact and what to do for a suspected compromise.

These are handy to keep to hand, or to hand to a client or a stand-in who does not have a login.

Setting it up on a site

1. 1
   Open the website from your Domains list and go to its Contacts tab, under Workspace.
2. 2
   Add the key people: assign an existing pooled contact, or create a new one, for each relevant type (developer, hosting, registrar and so on).
3. 3
   Mark the most important contact of each type as the primary, so it leads the emergency guide.
4. 4
   Write the "if it goes down" runbook, one step per line, in the order you would actually work through them.
5. 5
   Optionally download the emergency guide PDF to keep offline, and repeat for your other sites.

Where to set this up

Good to know

• Contacts live in a shared pool, so a provider entered once can be assigned to many sites and updated in one place.
• One contact per type can be the primary; that is the one that leads the emergency guide.
• The runbook is per-site free text, saved as one step per line, and editable any time.
• Two PDF guides can be downloaded per site: a general emergency guide and an "if hacked" guide.
• Keep login secrets in the credentials vault and reference them from the runbook, rather than writing passwords into the runbook itself.