When you issue reconcile as a part of synchronizing the target database, whether it be a first time activation and sync or it is subsequent resync, you can expect the command to finish very soon. There are times when it may take longer than what you expected, and the reason can be many.
The problem is that you only get the control of the session (or in other words the prompt only comes back) when the command finishes, either successfully or otherwise. So there is no way to know about its progress.
Since the prompt does not come back, one cannot know about its progress using the same session
An easy way to check the progress of reconcile is to open another sp_ctrl session and keep issuing "qstatus" from that session. The queue(s) that is/are currently being reconciled will have the same # of messages or they will keep increasing gradually depending on the activity on the source database. On the other hand the backlog will keep dropping rapidly if reconcile is doing its job.
The backlog will eventually shrink to a very small number or at least it will not drop rapidly as it was doing earlier. This signals that either the reconcile finished or is waiting for the messages to come over from source for an archive log higher than the one up to which reconcile was issued. In case of former the sp_ctrl prompt would have returned by now in the original session where the reconcile was issued. In case of latter, one has to wait for the activity on the source system to generate the requisite transaction from the next archive log that will prompt reconcile to finish.