When using the probe it can be helpful to understand how the probe works so you can know the limitations of the feature.
As an aside, when you turn on the probe on a service, this is considered a service configuration change like any other change to the device. This will mean that existing connections can be torn down and the service will be temporarily unavailible while it is reconfigured.
Getting back to my main point, the probe works by essentially adding a 'hidden' debug action into the rules between all the other actions, as well as 1 action first and 1 last. That is to say the probe only runs in the framework of multistep. These actions go in all rules: request, response, error, even in a called rule.
What does this mean in practice? Well, the probe is great for checking the inputs and outputs of your stylesheets. However, for the lower level protocol details, the probe is not designed to be 100% correct. Take HTTP for example, there are some hop-by-hop headers that are stripped before multistep runs, so you will not see those in the probe. Also, some headers are only calculated and added just as the data is to go on the wire (such as the Content-Length), so those again may differ from what you see in the probe.
Finally, it is often noted that the probe can change the Content-Type header.
This is not to suggest that you should not use the probe in development. It is a useful tool, as long as you are aware of its limitations.
P.S. - You cannot enable the probe on a scheduled rule.