When a configuration update fails

A failed configuration update means a change you made — adding a domain, adjusting a capability, or connecting a service — couldn't be applied to your server. Your server keeps running on its previous working configuration. Nothing was taken down and nothing is broken. The new change just wasn't applied yet.

What to do

1. Open the operation and read what it reports. The failed update records where it stopped. That usually tells you whether the problem is with the change itself or something about the server's current state.
2. Check that your server is reachable. Go to your server's page and confirm it shows as online. A server that can't be reached can't receive a configuration update.
3. Review any pending changes. Your server's configuration tab shows what changes are waiting to be applied. If you made several changes recently, consider whether any of them might conflict — for example, a domain that isn't set up in DNS yet, or a service that isn't ready to be connected.
4. Try applying the update again. From your server page, trigger another configuration update. Most failures are transient — a brief connectivity issue or the server being busy during the attempt. A second attempt often succeeds.

If updates keep failing after retrying and your server is otherwise healthy, reach out and we'll look at the operation details with you.

When updates haven't reached a server for a while

Occasionally a server stops accepting configuration updates altogether rather than failing one change — every attempt fails for the same underlying reason. When that has been going on for two days, you'll get a notification saying changes aren't reaching that server.

It matters because it's wider than the one change you were making. While a server is in this state, nothing new reaches it: not the change you queued, and not the security updates strackt would normally apply for you. Your applications keep running on the configuration already on the server, and your data is unaffected.

This one isn't yours to fix. Our operators are notified automatically, well before you hear about it. Retrying won't help, and there's no setting on your side that changes the outcome.

What to do:

1. Get in touch if the timing matters to you. If you're waiting on a specific change, tell us and we'll tell you where it stands. This is the useful step — the others are just housekeeping.
2. Consider holding off on queueing more changes to that server. Nothing you've already queued is lost, but stacking more up in the meantime makes it harder to see what has and hasn't landed.

You'll get a second notification when changes are reaching the server again.

When returning to the previous configuration doesn't complete

When strackt applies a change, it does so in a way that can be undone: if the new configuration doesn't come up cleanly, your server automatically returns to the last working one. You almost never see this happen — it's the safety net that lets updates be applied without risk.

Very occasionally that automatic return doesn't finish smoothly, and the server may report as unhealthy or briefly unreachable while it settles. Your applications and data are not lost — the server's previous working configuration is still on it — but it may need a moment, or a nudge, to come fully back.

What to do:

1. Give it a few minutes, then recheck the server's status. A server that's mid-way through settling often comes back online on its own once it finishes restarting.
2. Confirm the server is reachable. Open the server's page. If it's back online and healthy, the previous configuration is in place and you can safely try your change again.
3. Don't stack more changes on top yet. Wait until the server reports healthy before queueing another configuration update, so a new change isn't applied while the server is still recovering.

If the server stays unhealthy or unreachable for more than a few minutes, reach out straight away — this is one to look at together rather than keep retrying.