For the ministries we serve

Support

How to reach us, what you control, and how to take your site elsewhere — or leave altogether — if you ever need to.

Getting help

Support runs through a single Google Group. Posting there reaches everyone who works on JTCM sites, so requests don’t get stuck with one person who happens to be away.

Email: jtcm-support@googlegroups.com

Email JTCM support

What to include

  • Which site or app you’re writing about.
  • The page address, if it’s about something specific on the site.
  • What you expected to happen and what happened instead — a screenshot usually saves a round trip.
  • Whether anything is currently broken for visitors, so we know what to pick up first.

Your domain stays yours

Every ministry we work with registers and holds its own domain name in its own account. We don’t register domains on your behalf and we don’t hold them for you. Your domain is the one piece that decides where your visitors end up, so it should never be something you have to ask us for.

In practice that means:

  • The registrar account is in the ministry’s name, paid for by the ministry, with the ministry’s email on it.
  • You can point the domain somewhere else at any time, without our permission and without our involvement.
  • If we ever need DNS access to set something up, it’s access you grant and can withdraw.
  • If you decide to move to another provider or another volunteer, the domain moves with you.

Before you change anything

Write down your current DNS records exactly as they are — or take a screenshot of the whole list. That record is what makes the rollback below quick and certain rather than a guess.

Rolling back a DNS change

If a change to your site goes wrong, the fastest way back is usually to point your domain at whatever was serving it before. You can do this yourself, at your registrar, without waiting for us.

Plan ahead if you can

At least a day before a planned change, lower the TTL on the records you’re going to touch to 300 seconds. TTL is how long the rest of the internet is allowed to cache the old answer, so a low TTL turns a rollback from “up to two days” into “about five minutes”.

Steps

  1. Sign in to your registrar or DNS host — whoever holds the domain — and open the DNS records for your domain.
  2. Restore the records you changed to their previous values, exactly as you recorded them. For a website this is usually the A record on the bare domain and the CNAME on www.
  3. Leave MX and TXT records alone. Those carry your email and your domain verifications, and they are independent of where the website points. Deleting them is the one mistake that turns a website problem into an email outage.
  4. Save, then wait for the old TTL to expire. If the TTL was still at its default, allow up to 24–48 hours for every network to catch up.
  5. Check what the internet is actually seeing, rather than what your own browser shows — a browser will happily serve you a cached page long after DNS has changed.

Checking a rollback took effect

From a terminal:

dig yourdomain.com +short
dig www.yourdomain.com +short

Or use a site like whatsmydns.net, which shows what DNS servers around the world are returning for your domain — useful because propagation is uneven.

If you’re unsure at any point, write to the support group. Rolling back is not something you need our approval for, but we’re glad to look over your shoulder while you do it.

Requesting a code snapshot

You can ask for a copy of the code behind your site at any time, for any reason — a handover to another developer, your own archive, or just wanting it on file. You don’t need to justify the request.

What you get

  • A dated archive of the full source for your site, including its content, configuration and build setup.
  • Enough to build and host the site elsewhere without us, plus notes on how to do that.
  • Any content you supplied — text, images, documents — in its original form.

What isn’t included, and why

We can’t give out access to the live repository itself. Our code for every ministry we serve lives in one shared repository, so access to it is access to other ministries’ sites, their content, and in some cases their private material. That isn’t ours to hand over, and the same protection applies to your site when someone else asks.

Snapshots also leave out credentials, API keys and service account files. Those are tied to accounts rather than to code, and we’ll walk you through reissuing them in your own name if you’re moving the site.

How to request one

Email us saying which site you want a snapshot of and where to send it.

Ending the arrangement

You can tell us at any time that you’d like to stop working with us. That’s genuinely no problem, you don’t owe us an explanation, and it won’t affect how we treat you on the way out.

Nothing about the way we set things up is designed to make leaving hard. Your domain is already yours, your content is already yours, and you can have the code whenever you ask for it. Any one of those is enough to keep your site running without us.

What we’ll do

  • Send you a current code snapshot and a written summary of how the site is built, hosted and deployed.
  • Help you or your new developer get it running somewhere else, and stay reachable while you do it.
  • Hand over or reissue anything held in our accounts on your behalf, and tell you plainly about anything that can’t transfer.
  • Keep your site up until you’re ready to switch, so there’s no gap where visitors see nothing.

If something’s not working

If the reason you’re thinking about leaving is something we could fix, we’d rather hear it — but you’re under no obligation to raise it first.