diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 91da3c26ba0..e4e4c56cf14 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -925,6 +925,17 @@ test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/0
     to manage. For a large database all of which is heavily modified,
     incremental backups won't be much smaller than full backups.
    </para>
+
+   <para>
+    An incremental backup is only possible if replay would begin from a later
+    checkpoint than for the previous backup upon which it depends.  If you
+    take the incremental backup on the primary, this condition is always
+    satisfied, because each backup triggers a new checkpoint.  On a standby,
+    replay begins from the most recent restartpoint.  Therefore, an
+    incremental backup of a standby server can fail if there has been very
+    little activity since the previous backup, since no new restartpoint might
+    have been created.
+   </para>
   </sect2>
 
   <sect2 id="backup-lowlevel-base-backup">
diff --git a/src/backend/backup/basebackup_incremental.c b/src/backend/backup/basebackup_incremental.c
index 21087023973..a023e624403 100644
--- a/src/backend/backup/basebackup_incremental.c
+++ b/src/backend/backup/basebackup_incremental.c
@@ -441,7 +441,8 @@ PrepareForIncrementalBackup(IncrementalBackupInfo *ib,
 						 errmsg("manifest requires WAL from final timeline %u ending at %X/%X, but this backup starts at %X/%X",
 								range->tli,
 								LSN_FORMAT_ARGS(range->end_lsn),
-								LSN_FORMAT_ARGS(backup_state->startpoint))));
+								LSN_FORMAT_ARGS(backup_state->startpoint)),
+						 errhint("This can happen for incremental backups on a standby if there was little activity since the previous backup.")));
 		}
 		else
 		{