The below passage is quoted from https://diataxis.fr/how-to-guides/#writing-a-good-how-to-guide
Like a tutorial, a how-to guide contains a sequence of actions, that have an order. Unlike a tutorial, you don’t have to start at the beginning of the whole story and take your reader right to the end. Most likely, your user will also be in the middle of something - so you only need to provide a starting-point that they know how to reach, and a conclusion that actually answers a real question.
How-to guides should be reliable, but they don’t need to have the cast-iron repeatability of a tutorial.
The problem or task is the concern of a how-to guide: stick to that practical goal. Anything else that’s added - unnecessary explanation, for example - distracts both you and the user and dilutes the useful power of the guide.
An explanation doesn’t show you how to do something - so a how-to guide should not try to explain things. Explanation here will simply get in the way of the action. If explanations are important, link to them.
A tutorial needs to be didactic in nature, but a how-to guide needs to be adaptable to real-world use-cases. A how-to guide that is useless for any purpose except exactly the narrow one you have addressed is rarely valuable.
In how-to guides, practical usability is more helpful than completeness. Whereas a tutorial needs to be a complete, end-to-end guide, a how-to guide does not. It should start and end in some reasonable, meaningful place, and require the reader to join it up to their own work.
Choose titles that say exactly what a how-to guide shows.
How to integrate application performance monitoring
good
Integrating application performance monitoring
bad: maybe the document is about how to decide whether you should, not about how to do it.
Application performance monitoring
very bad: maybe it’s about how - but maybe it’s about whether, or even just an explanation of what it is
Note that search engines appreciate good titles just as much as humans do.