# Check Auth0 API Status using NodeJS

**URL:** <https://community.auth0.com/t/check-auth0-api-status-using-nodejs/93765>\
**Category:** Get Help\
**Tags:** nodejs, auth0\
**Created:** [November 4, 2022, 10:11pm UTC](https://community.auth0.com/t/check-auth0-api-status-using-nodejs/93765 "2022-11-04T22:11:47Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![scottcp](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/scottcp/32/41103_2.png) [@scottcp](https://community.auth0.com/u/scottcp)\
**Post date:** [November 4, 2022, 10:11pm UTC](https://community.auth0.com/t/check-auth0-api-status-using-nodejs/93765/1 "2022-11-04T22:11:47Z")

</div>

Hi,  
I have an application that logs the user in via Auth0. The user is redirected to a web browser to log in. I want to do a check to verify the service is available before sending the user so the user can be alerted if the service is not available to them for one reason or another. Is there a call to the Auth0 API that can be done without a token to verify that my domain is reachable to the client before sending them to the browser to log in? I’m sure I could ping it but that doesn’t definitely prove the service is available looking for a more detailed response.

Thanks  
Scott

---

<div class="post-metadata">

**Author:** ![dan.woda](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/dan.woda/32/18340_2.png) [@dan.woda](https://community.auth0.com/u/dan.woda)\
**Post date:** [November 7, 2022, 6:32pm UTC](https://community.auth0.com/t/check-auth0-api-status-using-nodejs/93765/3 "2022-11-07T18:32:35Z")

</div>

Hi @scottcp,

Welcome to the Auth0 Community!

There is an Atom/RSS feed that you can subscribe to for status updates. It’s listed at the bottom of the [https://status.auth0.com/](https://status.auth0.com/) page.

Given the authentication services generally have 99.999%+ uptime, I wouldn’t suggest making a call every time a user authenticates.

---

<div class="post-metadata">

**Author:** ![scottcp](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/scottcp/32/41103_2.png) [@scottcp](https://community.auth0.com/u/scottcp)\
**Post date:** [November 7, 2022, 6:54pm UTC](https://community.auth0.com/t/check-auth0-api-status-using-nodejs/93765/4 "2022-11-07T18:54:21Z")

</div>

Thanks Dan,

I appreciate your help. I was looking more for a JSON response for my specific server. If that’s not possible I suppose I can parse the Atom feed. How up-to-date is the status page? I’m really looking for something to verify that the information is reachable. If there is a routing issue or other type of issue that is not recognized by the status page.

---

<div class="post-metadata">

**Author:** ![dan.woda](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/dan.woda/32/18340_2.png) [@dan.woda](https://community.auth0.com/u/dan.woda)\
**Post date:** [November 7, 2022, 8:02pm UTC](https://community.auth0.com/t/check-auth0-api-status-using-nodejs/93765/5 "2022-11-07T20:02:44Z")

</div>

The Status Page is updated once an outage is known, so it wouldn’t address the use case you listed.

I wouldn’t recommend doing what you are describing, regardless.

---

<div class="post-metadata">

**Author:** ![scottcp](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/scottcp/32/41103_2.png) [@scottcp](https://community.auth0.com/u/scottcp)\
**Post date:** [November 7, 2022, 8:51pm UTC](https://community.auth0.com/t/check-auth0-api-status-using-nodejs/93765/6 "2022-11-07T20:51:44Z")

</div>

Thank you for your response, can you describe what the best practice would be for a backup authentication should auth0 become unavailable? As of course at some point is inevitable for it to occur.

---

<div class="post-metadata">

**Author:** ![dan.woda](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/dan.woda/32/18340_2.png) [@dan.woda](https://community.auth0.com/u/dan.woda)\
**Post date:** [November 7, 2022, 9:30pm UTC](https://community.auth0.com/t/check-auth0-api-status-using-nodejs/93765/7 "2022-11-07T21:30:04Z")

</div>

Most of our customers don’t have a failover auth service in place. Like I mentioned, [our services have nearly zero downtime](https://auth0.com/blog/auth0-guarantees-99-99-availability-on-public-cloud/).

If you require more control, you may want to consider [a private cloud deployment](https://auth0.com/cloud-deployment).

---

<div class="post-metadata">

**Author:** ![scottcp](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/scottcp/32/41103_2.png) [@scottcp](https://community.auth0.com/u/scottcp)\
**Post date:** [November 7, 2022, 9:54pm UTC](https://community.auth0.com/t/check-auth0-api-status-using-nodejs/93765/8 "2022-11-07T21:54:03Z")

</div>

Thank you for your answers, Dan! It seems a bit odd that no one has created and you wouldn’t encourage a backup plan. I’ve never used a service a backup wouldn’t make more robust by adding a failover. It doesn’t seem responsible to not have a backup plan. I’m going to design something using the current API. Regardless of the fact that you might not suggest this, it would most definitely be helpful to know if there is a technical or security reason why you would not suggest this.

I don’t see any advantages of downtime for private cloud deployments.

---

<div class="post-metadata">

**Author:** ![dan.woda](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/dan.woda/32/18340_2.png) [@dan.woda](https://community.auth0.com/u/dan.woda)\
**Post date:** [November 7, 2022, 10:24pm UTC](https://community.auth0.com/t/check-auth0-api-status-using-nodejs/93765/9 "2022-11-07T22:24:45Z")

</div>

> [@scottcp](#):
>
> It seems a bit odd that no one has created and you wouldn’t encourage a backup plan.

Just to be clear, that’s not what I said.

I said many of our customers don’t find it necessary due to the near-zero downtime.

> [@scottcp](#):
>
> I don’t see any advantages of downtime for private cloud deployments.

From the private cloud one-pager:

> Private deployments of Auth0 enable enterprise teams with:
> 
> - Fully isolated pre-production environments  
> that update independently from the  
> production environment
> - Scheduled updates of the Auth0 platform on  
> your timelines with the ability to roll back  
> releases if necessary
> - Hardened releases, validated by millions of  
> customers in the public cloud before they  
> touch your secure environment

---

<div class="post-metadata">

**Author:** ![scottcp](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/scottcp/32/41103_2.png) [@scottcp](https://community.auth0.com/u/scottcp)\
**Post date:** [November 7, 2022, 10:53pm UTC](https://community.auth0.com/t/check-auth0-api-status-using-nodejs/93765/10 "2022-11-07T22:53:16Z")

</div>

I appreciate your time Dan, you are correct, you did say that most of your customers don’t have a failover auth service in place and I apologize misreading that. I’d still like to go with a way to do this that directs our login to a backcup/failover service completely separate from Auth0 for better autonomy of the services. I see there is not a direct way to detect if the service is available, I appreciate your time. Have a great day!

---

<div class="post-metadata">

**Author:** ![dan.woda](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/dan.woda/32/18340_2.png) [@dan.woda](https://community.auth0.com/u/dan.woda)\
**Post date:** [November 7, 2022, 10:55pm UTC](https://community.auth0.com/t/check-auth0-api-status-using-nodejs/93765/11 "2022-11-07T22:55:49Z")

</div>

Thanks Scott!

Please let us know if you run into anything else. Cheers!

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/auth0/original/3X/b/5/b560f266932fcce5d57f09a6595bd50518cae3f3.jpeg) [@system](https://community.auth0.com/u/system)\
**Post date:** [November 21, 2022, 10:56pm UTC](https://community.auth0.com/t/check-auth0-api-status-using-nodejs/93765/12 "2022-11-21T22:56:25Z")

</div>

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
