diff --git a/.changeset/rich-apes-mix.md b/.changeset/rich-apes-mix.md
new file mode 100644
index 0000000000..3ba092c282
--- /dev/null
+++ b/.changeset/rich-apes-mix.md
@@ -0,0 +1,5 @@
+---
+'@backstage/plugin-catalog': patch
+---
+
+Add docs about config option to auto clean up orphans
diff --git a/docs/features/software-catalog/life-of-an-entity.md b/docs/features/software-catalog/life-of-an-entity.md
index 618923289e..583be7df20 100644
--- a/docs/features/software-catalog/life-of-an-entity.md
+++ b/docs/features/software-catalog/life-of-an-entity.md
@@ -222,7 +222,8 @@ either, it becomes _orphaned_. The end result is as follows:
 - The stitching process injects a `backstage.io/orphan: 'true'` annotation on
   the child entity.
 - The child entity is _not_ removed from the catalog, but stays around until
-  explicitly deleted via the catalog API, or "reclaimed" by the original parent
+  explicitly deleted via the catalog API, implicitly if `orphanStrategy: delete`
+  configuration is set, or until it is "reclaimed" by the original parent
   or another parent starting to reference it.
 - The catalog page in Backstage for the child entity detects the new annotation
   and informs users about the orphan status.
@@ -259,9 +260,13 @@ entities without explicit owner consent. The catalog therefore takes the stance
 that entities that often were added by direct user action should also be deleted
 only by direct user action.
 
-It is possible to use the catalog API to build automated "reaper" systems that
-finally delete entities that are orphaned. This is however not something that's
-provided out of the box.
+However, if you want to delete orphaned entities automatically anyway, you can
+enable the automated clean up with the following app-config option.
+
+```
+catalog:
+  orphanStrategy: delete
+```
 
 ## Implicit Deletion