diff --git a/source/_integrations/profiler.markdown b/source/_integrations/profiler.markdown
index f9c05e48d0d..350e72b3f3c 100644
--- a/source/_integrations/profiler.markdown
+++ b/source/_integrations/profiler.markdown
@@ -16,7 +16,7 @@ The Profiler integration provides a profile which is a set of statistics that id
 
 {% include integrations/config_flow.md %}
 
-### Service `profiler.start`
+### Service {% my developer_call_service service="profiler.start" %}
 
 Start the profiler for the specified number of seconds.
 
@@ -51,7 +51,7 @@ dot callgrind.dot -Tpng -o callgrind.png
 gprof2dot -f pstats profile.1234567890123456.cprof | dot -Tsvg -o profile.svg
 ```
 
-### Service `profiler.memory`
+### Service {% my developer_call_service service="profiler.memory" %}
 
 <div class='note warning'>
 This service is unavailable when using Python 3.11 as the underlying guppy3 library does not yet support Python 3.11.
@@ -73,7 +73,7 @@ from guppy import hpy
 hpy().pb()
 ```
 
-### Service `profiler.start_log_objects`
+### Service {% my developer_call_service service="profiler.start_log_objects" %}
 
 Start logging the growth of objects in memory.
 
@@ -83,11 +83,11 @@ Start logging the growth of objects in memory.
 
 Periodically log the growth of new objects in memory. This service's primary use case is finding memory leaks. This service can be run for long periods to find slow leaks. For finding fast leaks, `profiler.start_log_object_sources` is preferred; however, it is much more CPU intensive.
 
-### Service `profiler.stop_log_objects`
+### Service {% my developer_call_service service="profiler.stop_log_objects" %}
 
 Stop logging the growth of objects in memory.
 
-### Service `profiler.start_log_object_sources`
+### Service {% my developer_call_service service="profiler.start_log_object_sources" %}
 
 Start logging the growth of objects in memory and attempt to find the source of the new objects.
 
@@ -100,11 +100,11 @@ Periodically log the growth of new objects in memory. This service's primary use
 
 This service is similar to `start_log_objects` except that it is much more CPU intensive since it will attempt to locate the source of each new object up to `max_objects` each time it logs.
 
-### Service `profiler.stop_log_object_sources`
+### Service {% my developer_call_service service="profiler.stop_log_object_sources" %}
 
 Stop logging the growth of objects with sources in memory.
 
-### Service `profiler.dump_log_objects`
+### Service {% my developer_call_service service="profiler.dump_log_objects" %}
 
 | Service data attribute | Optional | Description |
 | ---------------------- | -------- | ----------- |
@@ -112,7 +112,20 @@ Stop logging the growth of objects with sources in memory.
 
 When `start_log_objects` highlights the growth of a collection of objects in memory, this service can help investigate. The `repr` of each object that matches `type` will be logged.
 
-### Service `profiler.log_thread_frames`
+This service is useful for investigating the state of objects in memory. For example, if your system has templates that are rendering too frequently, the below example service calls shows how to find which templates are the source of the problem:
+
+```yaml
+service: profiler.dump_log_objects
+data:
+  type: RenderInfo
+```
+```yaml
+service: profiler.dump_log_objects
+data:
+  type: Template
+```
+
+### Service {% my developer_call_service service="profiler.log_thread_frames" %}
 
 To help discover run away threads, why the executor is overloaded, or other threading problems, the current frames for each running thread will be logged when this service is called.
 
@@ -147,7 +160,7 @@ An example is below:
     sock.connect(address)
 ```
 
-### Service `profiler.log_event_loop_scheduled`
+### Service {% my developer_call_service service="profiler.log_event_loop_scheduled" %}
 
 Log what is scheduled in the event loop. This can be helpful in tracking down integrations that do not stop listeners when Home Assistant stops or do not have sufficient locking to avoid scheduling updates before the previous update is finished.
 
@@ -155,6 +168,6 @@ Each upcoming scheduled item is logged similar to the below example:
 
 `[homeassistant.components.profiler] Scheduled: <TimerHandle when=1528307.1818668307 async_track_point_in_utc_time.<locals>.run_action(<Job HassJobType.Coroutinefunction <bound method DataUpdateCoordinator._handle_refresh_interval of <homeassistant.components.screenlogic.ScreenlogicDataUpdateCoordinator object at 0x7f985d896d30>>>) at /usr/src/homeassistant/homeassistant/helpers/event.py:1175>`
 
-### Service `profiler.lru_stats`
+### Service {% my developer_call_service service="profiler.lru_stats" %}
 
 Logs statistics from [lru_cache](https://docs.python.org/3/library/functools.html#functools.lru_cache) and [lru-dict](https://pypi.org/project/lru-dict/) to help tune Home Assistant and locate memory leaks.