From 7dbad92254af6fb9346ac72fd46d2562693ae117 Mon Sep 17 00:00:00 2001
From: 3wc <3wc@doesthisthing.work>
Date: Mon, 11 Apr 2022 03:02:48 +0200
Subject: [PATCH] Fix link to architecture explanation

Thanks @dantefromhell
---
 docs/intro/faq.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/intro/faq.md b/docs/intro/faq.md
index 1d54abe..b115c34 100644
--- a/docs/intro/faq.md
+++ b/docs/intro/faq.md
@@ -210,7 +210,7 @@ We are happy to see the compose specification emerging as a new open standard be
 
 ## Why Docker Swarm?
 
-While many have noted that "swarm is dead" it is in fact [not dead](https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-develop-docker-swarm/). As detailed in the [architecture overview page](/overview/#container-orchestrator), swarm offers an appropriate feature set which allows us to support zero-down time upgrades, seamless app rollbacks, automatic deploy failure handling, scaling, hybrid cloud setups and maintain a decentralised design.
+While many have noted that "swarm is dead" it is in fact [not dead](https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-develop-docker-swarm/). As detailed in the [architecture overview](/operators/tutorial/#container-orchestrator), swarm offers an appropriate feature set which allows us to support zero-down time upgrades, seamless app rollbacks, automatic deploy failure handling, scaling, hybrid cloud setups and maintain a decentralised design.
 
 While the industry is bordering on a [k8s](https://kubernetes.io/) obsession and the need to [scale down](https://microk8s.io/) a tool that was fundamentally built for massive scale, we are going with swarm because it is the tool most suitable for [small technology](https://small-tech.org/).