diff --git a/README.md b/README.md
index c7a2ef2c..32517b1f 100644
--- a/README.md
+++ b/README.md
@@ -609,6 +609,8 @@ end
 
 It's possible to run multiple schedulers with the same `recurring_tasks` configuration, for example, if you have multiple servers for redundancy, and you run the `scheduler` in more than one of them. To avoid enqueuing duplicate tasks at the same time, an entry in a new `solid_queue_recurring_executions` table is created in the same transaction as the job is enqueued. This table has a unique index on `task_key` and `run_at`, ensuring only one entry per task per time will be created. This only works if you have `preserve_finished_jobs` set to `true` (the default), and the guarantee applies as long as you keep the jobs around.
 
+**Note**: It is possible to have different `queue_adapter` settings set for different ActiveJob::Base` subclasses. While solid_queue supports this feature, it will not be aware that a job which is scheduled has, indeed, been enqueued for execution - as Solid Queue only sees its own `jobs` table as the source of truth, and can't "peek" into other adapters' queues. This means that recurring tasks which enqueue jobs into other adapters will reinsert them into their respective adapter repeatedly, every time the recurring tasks are getting scheduled. This is almost certainly not something that you want, so as a rule of thumb: a job class used by a recurring task must be enqueued into Solid Queue and into Solid Queue only.
+
 **Note**: a single recurring schedule is supported, so you can have multiple schedulers using the same schedule, but not multiple schedulers using different configurations.
 
 Finally, it's possible to configure jobs that aren't handled by Solid Queue. That is, you can have a job like this in your app: