API Performance & Error Monitoring MVP

Wes Wagner

Hi all, I wanted to share an MVP we developed internally at Rarely Decaf to help us better serve our clients.

• The problem: Monitoring API errors and performance using Xano's built in Request History feature is time-consuming.
• The solution: A dashboard that allows us to quickly get visibility into API error frequency and performance issues by endpoint.

This solution was enabled by the new metadata API, which allows us to now capture and store up to the past 24 hours of API request history

How it it works: We have a cron job in Google Cloud that fetches and stores certain parameters of Xano's request history in BigQuery. Then, we visualize this request history in Google Data Studio.

Has anyone else done anything similar?

Michael Udinski

This looks awesome @Wes Wagner! I love seeing all the cool use-cases unlocked by the Metadata API. Thank you for sharing :)

Wes Wagner

No problem, @Michael Udinski!

Also, a quick heads up that the documentation here mentions that created_at should be a timestamp in milliseconds. However, in practice, it looks like it actually only accepts ISO 8601.

Michael Udinski

Hmmm thanks for pointing that out, we'll be sure to update this!

Wes Wagner

On a related note, is there anyway to programmatically get data associated with API groups and endpoints @Michael Udinski? It'd be nice to pull in additional context here—such as the name of the API (not the URI) and description.

Michael Udinski

Hi @Wes Wagner — we checked and verified that UNIX timestamps in MS is in fact compatible and working as documented with the Metadata API.

Pulling the API description is not yet a part of the beta Metadata API. Wouldn't the API name already be a part of the entire URL? Just combined with the base URL.

Wes Wagner

Hi @Michael Udinski, I apologize for the confusion.

I just went through and tested using unix timestamps in seconds and ms as well as testing the ISO format.

From my testing, timestamps in seconds worked, ISO 8601 worked, but timestamp in milliseconds did not work for me.

Based on the screenshots, let me know if I'm doing something wrong.

Pulling the API description is not yet a part of the beta Metadata API. Wouldn't the API name already be a part of the entire URL? Just combined with the base URL.

For most APIs—absolutely.

However, for APIs that have dynamic variables in them—such as /customers/{customers_id}—that's not the case. So, in order for us to use the data from the metadata API to analyze performance or errors on an endpoint level (and know that /customers/1 and customers/2 are likely the same endpoint) we have to use the query_id.

Alternatively, I imagine we could create some logic before the API response data goes to our BigQuery database to group get /customers/1 and customers/2 together, but not just remove the integers (as we could confuse the get all endpoint with the get individual record endpoint), but I didn't want to go down that rabbit hole to account for all of our endpoints.

It's not the end of the world, but it does mean we have to jump between the Google Data Studio report above and control-f in Xano (using the query_id) to understand which is the problematic API.