# Uptime discovery/self registration

**URL:** <https://discuss.elastic.co/t/uptime-discovery-self-registration/287294>\
**Category:** Elastic Observability\
**Created:** [October 21, 2021, 9:38am UTC](https://discuss.elastic.co/t/uptime-discovery-self-registration/287294 "2021-10-21T09:38:31Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bert\_Vanpeteghem](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bert_vanpeteghem/32/96191_2.png) [@Bert\_Vanpeteghem](https://discuss.elastic.co/u/Bert_Vanpeteghem)\
**Post date:** [October 21, 2021, 9:38am UTC](https://discuss.elastic.co/t/uptime-discovery-self-registration/287294/1 "2021-10-21T09:38:31Z")

</div>

Hi, is it possible to have some kind of discovery/self registration for applications and services in Elastic Uptime?

So that applications can register the required uptime checks and alerting without having to bother the elastic admin?

---

<div class="post-metadata">

**Author:** ![riferrei](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/riferrei/32/104867_2.png) [@riferrei](https://discuss.elastic.co/u/riferrei)\
**Post date:** [October 25, 2021, 5:01pm UTC](https://discuss.elastic.co/t/uptime-discovery-self-registration/287294/2 "2021-10-25T17:01:49Z")

</div>

Suppose your application/services are executed via Containers, K8S pods, or behind an AWS load balancer. In that case, you can use the [autodiscover](https://www.elastic.co/guide/en/beats/heartbeat/current/configuration-autodiscover.html) feature from Heartbeat to automatically add heartbeat probing to whatever containers/pods are spun up.

If you need an example, I recorded a tutorial in the YouTube channel from the Elastic community:

[![](https://us1.discourse-cdn.com/elastic/original/3X/f/4/f4420ecfe59fa6fb3c3902e5cdd379b5458ce20a.jpeg "Monitoring Docker Containers with Autodiscover") ](https://www.youtube.com/watch?v=_iW5s_iqBgU)

— @riferrei

---

<div class="post-metadata">

**Author:** ![Bert\_Vanpeteghem](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bert_vanpeteghem/32/96191_2.png) [@Bert\_Vanpeteghem](https://discuss.elastic.co/u/Bert_Vanpeteghem)\
**Post date:** [October 31, 2021, 3:16pm UTC](https://discuss.elastic.co/t/uptime-discovery-self-registration/287294/3 "2021-10-31T15:16:06Z")

</div>

Hi Ricardo, thanks for the reply. Our application landscap consists of both services within Kubernetes as services and applications outside of it. Is there any other option?

---

<div class="post-metadata">

**Author:** ![riferrei](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/riferrei/32/104867_2.png) [@riferrei](https://discuss.elastic.co/u/riferrei)\
**Post date:** [November 1, 2021, 1:44pm UTC](https://discuss.elastic.co/t/uptime-discovery-self-registration/287294/4 "2021-11-01T13:44:59Z")

</div>

In an _automatic way,_ only the options I listed before are supported OOTB, namely — K8S, Docker, and AWS Load Balancers. Services that are not using these approaches are supposed to have their uptime data collected manually. However, there are architectural designs you can follow to make up for them. As an example, you can build your services to communicate with each other via a service mesh, in which the data planes of these services could perform this uptime data collection on their behalf.

— @riferrei

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [November 4, 2022, 8:32am UTC](https://discuss.elastic.co/t/uptime-discovery-self-registration/287294/5 "2022-11-04T08:32:45Z")

</div>


