# APM UI Kibana Internal Server Error **URL:** \ **Category:** APM\ **Tags:** ui\ **Created:** [March 14, 2020, 5:44am UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601 "2020-03-14T05:44:02Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Rakesh\_B](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rakesh_b/32/48128_2.png) [@Rakesh\_B](https://discuss.elastic.co/u/Rakesh_B)\ **Post date:** [March 14, 2020, 5:44am UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/1 "2020-03-14T05:44:03Z")
**Kibana version** : 7.5.2 **Elasticsearch version** : 7.5.2 **APM Server version** : 7.6.0 **APM Agent language and version** : Java 1.12.0 We have 6 ES data instances each with 7 VCPUs and 62 GIB of RAM, with 23 GIB of HEAP. We are using EBS volumes and they are also functioning way below their max capacity. Kibana APM UI throws "Error: Request Timeout after 30000ms" for "1 day" worth data but the "Discovery" section of the Kibana can load 7 days worth of data which is around 1.6 Billion events. Our cluster health is normal and it is not overutilized. Even the Kibana pod is not overutilized ![Screen Shot 2020-03-13 at 10.40.17 PM](https://us1.discourse-cdn.com/elastic/original/3X/3/2/325ff836c2dd6e6a3a7b88b2c5756d4795bca2d5.png) "Internal Sever Error" in Kibana UI for APM: ![Screen Shot 2020-03-13 at 10.27.16 PM](https://us1.discourse-cdn.com/elastic/original/3X/a/5/a536efc430b8aafafd7c7771466b99b216565ea1.png) Discovery section in Kibana can load 7 days worth documents in less than 30 seconds: ![Screen Shot 2020-03-13 at 10.27.07 PM](https://us1.discourse-cdn.com/elastic/original/3X/e/9/e9a27e71a272009cda3492e362fa55c6909f73b5.png) I tried the same query in profiler and I got a response in less than 17 seconds. All the data, master and kibana nodes are working normally. I've also tried "client\_max\_body\_size 5000m;" in our nginx reverse proxy and it did not fix the problem. - Thank you ---
**Author:** ![sqren](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sqren/32/26110_2.png) [@sqren](https://discuss.elastic.co/u/sqren)\ **Post date:** [March 14, 2020, 7:41pm UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/2 "2020-03-14T19:41:40Z")
Hi there, Thanks for your interest in Elastic APM and making us aware of this issue. > [@Rakesh\_B](#): > > "Internal Sever Error" in Kibana UI for APM: This doesn't sound right and I'd like to dig a little deeper into this. In the APM app in Kibana we have a debugging mechanism that lets you dump the raw Elasticsearch query. I'd like you to try this. Open your browsers Developer Tools and find the XHR request that starts with `/api/apm/services`. You can enable debugging by adding `_debug=true` to the query params like: `/api/apm/services?_debug=true` This will dump the ES query in the Kibana logs. With the ES query you can now execute it directly in the Kibana Dev Tools. I would expect it to still timeout. You might find the [profile](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-profile.html) API useful in this regard. Very interested to hear what you find out. ---
**Author:** ![Rakesh\_B](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rakesh_b/32/48128_2.png) [@Rakesh\_B](https://discuss.elastic.co/u/Rakesh_B)\ **Post date:** [March 15, 2020, 2:36am UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/3 "2020-03-15T02:36:04Z")
Hi @sqren, Thank you for your reply. The indices were deleted as a part of ILM. I'm running more load tests to generate data to reproduce the error. In the mean time please let me know why changing the transaction\_sample\_rate from 1 to 0.00002 doesn't seem to have much effect on disk space usage. when the rate was set to 1 we ingested 1GB of data every 25 seconds and when the rate was set to 0.00002 we are ingesting 1GB every 1.5 minutes. I've also stopped ingesting headers and body as well. FYI: we are using elastic APM java agent with around 20 services and we get around 2 million requests every minute. Please let me know if I'm missing something else which is important to save disk space. - Thank you ---
**Author:** ![Rakesh\_B](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rakesh_b/32/48128_2.png) [@Rakesh\_B](https://discuss.elastic.co/u/Rakesh_B)\ **Post date:** [March 15, 2020, 6:09pm UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/4 "2020-03-15T18:09:19Z")
Hi @sqren, I generated more data and found the query in kibana logs for 3 days worth data which looks like this --DEBUG ES QUERY-- GET /api/apm/services {"\_debug":"true","start":"2020-03-12T18:03:29.441Z","end":"2020-03-15T18:03:29.441Z","uiFilters":"{}"} GET apm-_,apm-_,apm-\*/\_search { "size": 0, "query": { "bool": { "filter": [ { "terms": { "processor.event": [ "transaction", "error", "metric" ] } }, { "range": { "@timestamp": { "gte": 1584036209441, "lte": 1584295409441, "format": "epoch\_millis" } } }, { "range": { "observer.version\_major": { "gte": 7 } } } ] } }, "aggs": { "services": { "terms": { "field": "service.name", "size": 500 }, "aggs": { "avg": { "avg": { "field": "[transaction.duration.us](http://transaction.duration.us)" } }, "agents": { "terms": { "field": "agent.name", "size": 1 } }, "events": { "terms": { "field": "processor.event", "size": 2 } }, "environments": { "terms": { "field": "service.environment" } } } } } } Weird thing is that the query is timing out in the search profiler but not in the APM UI. ---
**Author:** ![Bingu\_Shim](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bingu_shim/32/57949_2.png) [@Bingu\_Shim](https://discuss.elastic.co/u/Bingu_Shim)\ **Post date:** [March 16, 2020, 1:17am UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/5 "2020-03-16T01:17:32Z")
This is because the transaction\_sample\_rate only affects to apm-span-\* index. It stores all transactions to the apm-transaction index no matter what the transaction\_sample\_rate is set. I think this is the real reason why APM UI is that SLOW, and since it's architectural problem this slowness issue is hard to solve with some tuning. If this is true, it should be very careful to apply Elastic APM to real operation environment. ---
**Author:** ![Bingu\_Shim](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bingu_shim/32/57949_2.png) [@Bingu\_Shim](https://discuss.elastic.co/u/Bingu_Shim)\ **Post date:** [March 16, 2020, 1:17am UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/6 "2020-03-16T01:17:50Z")
I also captured the slow query [HERE](https://docs.google.com/spreadsheets/d/1zBdXm1AttrwO52cAihk9eEdUuitQBdNZFbLC7Bk_Dy8/edit#gid=0) and replied [HERE](https://discuss.elastic.co/t/kibana-apm-app-pages-are-too-slow/220570/3) as sqren asked 20 days ago and still waiting his answer. ---
**Author:** ![Rakesh\_B](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rakesh_b/32/48128_2.png) [@Rakesh\_B](https://discuss.elastic.co/u/Rakesh_B)\ **Post date:** [March 16, 2020, 1:50am UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/7 "2020-03-16T01:50:22Z")
Yeah, I agree, cutting down transaction sample can only limit disk space to a certain limit. I'm able to read filebeat logs much faster than APM even though they take more disk space. APM is timing out even though CPU usage is very low. When I search for APM data for like 2 days it takes more than 30-40 seconds and also it doesn't use all the cores. Search queue is barely used. ---
**Author:** ![Bingu\_Shim](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bingu_shim/32/57949_2.png) [@Bingu\_Shim](https://discuss.elastic.co/u/Bingu_Shim)\ **Post date:** [March 16, 2020, 4:31am UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/8 "2020-03-16T04:31:06Z")
I also noticed that cpu usage is very low and also IOPS(I/O per seconds) is not that high. ---
**Author:** ![Rakesh\_B](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rakesh_b/32/48128_2.png) [@Rakesh\_B](https://discuss.elastic.co/u/Rakesh_B)\ **Post date:** [March 16, 2020, 4:51am UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/9 "2020-03-16T04:51:46Z")
Yeah, I see that too, CPU is very low for "SEARCHES" and response times are quite slow in the APM UI. I did see some improvement when I doubled the amount of vCPUs (also cut down the RAM by 50%, basically switched from r5.2xlarge to c5.4xlarge). But I still feel that APM queries doesn't use the full capacity of our cluster for search queries. We have 6 provisioned iops volumes with with 3000 IOPS but the peaks I'm seeing is less than 500 IOPS ---
**Author:** ![Rakesh\_B](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rakesh_b/32/48128_2.png) [@Rakesh\_B](https://discuss.elastic.co/u/Rakesh_B)\ **Post date:** [March 16, 2020, 4:55am UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/10 "2020-03-16T04:55:48Z")
one more issue I see is Kibana visualizations also take quite some time. Our kibana server is way underutilized. When I click on APM dashboard in Kibana it took around 35 seconds for the visualization to load. This might be a caching issue with Kibana though, after opening the APM UI for the first time, if I load a second tab it doesn't take 35 seconds. ---
**Author:** ![Rakesh\_B](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rakesh_b/32/48128_2.png) [@Rakesh\_B](https://discuss.elastic.co/u/Rakesh_B)\ **Post date:** [March 16, 2020, 3:47pm UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/11 "2020-03-16T15:47:56Z")
Hi @sqren, I generated enough data to reproduce the error again. I'm seeing timeout in the dev tools for a single day worth of logs. But I'm able to load all the logs in the discovery section easily for 2 days. Is there anything we can do make this run faster. CPU usage is less than 40% on all 6 nodes, some of them have less than 25%. Can we do something so that the nodes use full hardware capacity? We have 6 nodes and each index has 4 shards, total size of the indices in the last 2 days is 600GB (including 1 replica). FYI: Please note that we use a single "apm-YYYY.MM.DAY" index to store all of APM data like transactions, errors and spans. ![Screen Shot 2020-03-16 at 8.44.35 AM](https://us1.discourse-cdn.com/elastic/original/3X/2/d/2d3ef4ca5682287e79e49c4bf6cae348db531d97.png) - Thank you ---
**Author:** ![Rakesh\_B](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rakesh_b/32/48128_2.png) [@Rakesh\_B](https://discuss.elastic.co/u/Rakesh_B)\ **Post date:** [March 16, 2020, 5:08pm UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/12 "2020-03-16T17:08:34Z")
FYI: Please note that we use a single "apm-YYYY.MM.DAY" index to store all of APM data like transactions, errors and spans. ---
**Author:** ![Rakesh\_B](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rakesh_b/32/48128_2.png) [@Rakesh\_B](https://discuss.elastic.co/u/Rakesh_B)\ **Post date:** [March 16, 2020, 7:38pm UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/13 "2020-03-16T19:38:43Z")
Here are some slow logs when ES timed out while searching for 12 hours of APM logs ```auto {"type": "index_search_slowlog", "timestamp": "2020-03-16T19:09:47,438Z", "level": "WARN", "component": "i.s.s.query", "cluster.name": "elasticsearch", "node.name": "elasticsearch-es-data-4", "message": "[apm-7.6.0-2020.03.16][3]", "took": "45.5s", "took_millis": "45508", "total_hits": "10000+ hits", "stats": "[]", "search_type": "QUERY_THEN_FETCH", "total_shards": "12", "source": "{\"size\":0,\"query\":{\"bool\":{\"filter\":[{\"terms\":{\"processor.event\":[\"transaction\",\"error\",\"metric\"],\"boost\":1.0}},{\"range\":{\"@timestamp\":{\"from\":1584342540477,\"to\":1584385740477,\"include_lower\":true,\"include_upper\":true,\"format\":\"epoch_millis\",\"boost\":1.0}}},{\"range\":{\"observer.version_major\":{\"from\":7,\"to\":null,\"include_lower\":true,\"include_upper\":true,\"boost\":1.0}}}],\"adjust_pure_negative\":true,\"boost\":1.0}},\"aggregations\":{\"host\":{\"meta\":{},\"filter\":{\"match_all\":{\"boost\":1.0}},\"aggregations\":{\"by_terms\":{\"terms\":{\"field\":\"host.hostname\",\"size\":10,\"min_doc_count\":1,\"shard_min_doc_count\":0,\"show_term_doc_count_error\":false,\"order\":[{\"_count\":\"desc\"},{\"_key\":\"asc\"}]},\"aggregations\":{\"bucket_count\":{\"cardinality\":{\"field\":\"service.name\"}}}}}},\"agentName\":{\"meta\":{},\"filter\":{\"match_all\":{\"boost\":1.0}},\"aggregations\":{\"by_terms\":{\"terms\":{\"field\":\"agent.name\",\"size\":10,\"min_doc_count\":1,\"shard_min_doc_count\":0,\"show_term_doc_count_error\":false,\"order\":[{\"_count\":\"desc\"},{\"_key\":\"asc\"}]},\"aggregations\":{\"bucket_count\":{\"cardinality\":{\"field\":\"service.name\"}}}}}}}}", "cluster.uuid": "jktKncXUQ_yiDkjUepqUCg", "node.id": "yCTfEa-nSJi5QhH-W8Praw" } {"type": "index_search_slowlog", "timestamp": "2020-03-16T19:09:47,424Z", "level": "WARN", "component": "i.s.s.query", "cluster.name": "elasticsearch", "node.name": "elasticsearch-es-data-4", "message": "[apm-7.6.0-2020.03.16][3]", "took": "45.4s", "took_millis": "45426", "total_hits": "10000+ hits", "stats": "[]", "search_type": "QUERY_THEN_FETCH", "total_shards": "12", "source": "{\"size\":0,\"query\":{\"bool\":{\"filter\":[{\"terms\":{\"processor.event\":[\"transaction\",\"error\",\"metric\"],\"boost\":1.0}},{\"range\":{\"@timestamp\":{\"from\":1584342540477,\"to\":1584385740477,\"include_lower\":true,\"include_upper\":true,\"format\":\"epoch_millis\",\"boost\":1.0}}},{\"range\":{\"observer.version_major\":{\"from\":7,\"to\":null,\"include_lower\":true,\"include_upper\":true,\"boost\":1.0}}}],\"adjust_pure_negative\":true,\"boost\":1.0}},\"aggregations\":{\"services\":{\"terms\":{\"field\":\"service.name\",\"size\":500,\"min_doc_count\":1,\"shard_min_doc_count\":0,\"show_term_doc_count_error\":false,\"order\":[{\"_count\":\"desc\"},{\"_key\":\"asc\"}]},\"aggregations\":{\"avg\":{\"avg\":{\"field\":\"transaction.duration.us\"}},\"agents\":{\"terms\":{\"field\":\"agent.name\",\"size\":1,\"min_doc_count\":1,\"shard_min_doc_count\":0,\"show_term_doc_count_error\":false,\"order\":[{\"_count\":\"desc\"},{\"_key\":\"asc\"}]}},\"events\":{\"terms\":{\"field\":\"processor.event\",\"size\":2,\"min_doc_count\":1,\"shard_min_doc_count\":0,\"show_term_doc_count_error\":false,\"order\":[{\"_count\":\"desc\"},{\"_key\":\"asc\"}]}},\"environments\":{\"terms\":{\"field\":\"service.environment\",\"size\":10,\"min_doc_count\":1,\"shard_min_doc_count\":0,\"show_term_doc_count_error\":false,\"order\":[{\"_count\":\"desc\"},{\"_key\":\"asc\"}]}}}}}}", "cluster.uuid": "jktKncXUQ_yiDkjUepqUCg", "node.id": "yCTfEa-nSJi5QhH-W8Praw" } ``` AS you can see in the screenshots below CPU is not spiked at all, search queue is completely empty and there are no rejects in the queue. ![Screen Shot 2020-03-16 at 12.12.13 PM](https://us1.discourse-cdn.com/elastic/original/3X/c/f/cf5808ee3412a860293ce64227883e1aa437b82c.png) ![Screen Shot 2020-03-16 at 12.11.27 PM](https://us1.discourse-cdn.com/elastic/original/3X/2/3/23417b30536e140330c492ff1a7977953711310a.png) ![Screen Shot 2020-03-16 at 12.11.09 PM](https://us1.discourse-cdn.com/elastic/original/3X/e/7/e7c1dd0f259db351cc734f4e9c9ca84712d57338.png) ![Screen Shot 2020-03-16 at 12.10.48 PM](https://us1.discourse-cdn.com/elastic/original/3X/c/4/c46c6694d874f7f4652700d15c9223771d5023ad.png) ![Screen Shot 2020-03-16 at 12.17.13 PM](https://us1.discourse-cdn.com/elastic/original/3X/a/d/ad6780c02f415080d6fbfc983a6f540b16ff71c4.png) ---
**Author:** ![sqren](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sqren/32/26110_2.png) [@sqren](https://discuss.elastic.co/u/sqren)\ **Post date:** [March 17, 2020, 11:58am UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/14 "2020-03-17T11:58:17Z")
Hi, Thanks for taking the time to try this out. I see you are getting a "504 Gateway Timeout". How long before it times out? A couple of ideas: 1. Can you try connecting to elasticsearch directly, and not through the nginx proxy. Do you get a different result or different error message? 2. Try removing some of the aggregations in the `aggs` section of the query, so it looks like: ```json { "size": 0, "query": { ...same query }, "aggs": { "services": { "terms": { "field": "service.name", "size": 500 } } } } ``` Does this make the query complete? If yes, try re-adding some of the aggs and find out which one that causes the timeout. ---
**Author:** ![Rakesh\_B](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rakesh_b/32/48128_2.png) [@Rakesh\_B](https://discuss.elastic.co/u/Rakesh_B)\ **Post date:** [March 17, 2020, 4:47pm UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/15 "2020-03-17T16:47:33Z")
The default timeout period we have is `30 seconds`. We don't have an nginx in front of elasticsearch, our kibana talks to elasticsearch directly, (FYI: we do have nginx and oauth2-proxy in front of kibana though) I don't see timeouts when I remove some aggregations. Please check the below screenshots When I removed `all aggregations` for 3 days worth of data for a single service.: ![Screen Shot 2020-03-17 at 9.43.13 AM](https://us1.discourse-cdn.com/elastic/original/3X/3/2/325e448e49ae6f21b8651b4353bdd7f7ea31e140.png) When I removed `aggregations for transaction_results`: ![Screen Shot 2020-03-17 at 9.42.53 AM](https://us1.discourse-cdn.com/elastic/original/3X/b/a/baff7cd751dddf4d7d311dcec0787d13015deb50.png) When I removed `aggregations for response_times`: ![Screen Shot 2020-03-17 at 9.42.08 AM](https://us1.discourse-cdn.com/elastic/original/3X/4/9/4965c5aa020fa04ec3591997acd607d4de0a7086.png) ---
**Author:** ![sqren](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sqren/32/26110_2.png) [@sqren](https://discuss.elastic.co/u/sqren)\ **Post date:** [March 18, 2020, 7:53am UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/16 "2020-03-18T07:53:59Z")
Can you try to do the same with the `/api/apm/services` endpoint? It's a little simpler and in your initial post it sounded like that was also timing out ---
**Author:** ![sqren](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sqren/32/26110_2.png) [@sqren](https://discuss.elastic.co/u/sqren)\ **Post date:** [March 18, 2020, 7:55am UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/17 "2020-03-18T07:55:07Z")
... it's on the very first page of APM ui. The page that shows a list of services. ---
**Author:** ![Bingu\_Shim](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/bingu_shim/32/57949_2.png) [@Bingu\_Shim](https://discuss.elastic.co/u/Bingu_Shim)\ **Post date:** [March 18, 2020, 8:35am UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/18 "2020-03-18T08:35:42Z")
Hello @sqren Could you let us know any benchmarking result of APM UI done by development team internally? I found [THIS GUIDE](https://www.elastic.co/guide/en/apm/server/current/sizing-guide.html) and [THIS ISSUE](https://github.com/elastic/apm-server/issues/1414) which only focused on APM Server side. This slowness issue occur with ONLY SMALL amount of requests, and It's really hard to tune Elasticsearch for APM UI. In my point of view, it should be easier for Elastic APM to be widely used. ---
**Author:** ![Rakesh\_B](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rakesh_b/32/48128_2.png) [@Rakesh\_B](https://discuss.elastic.co/u/Rakesh_B)\ **Post date:** [March 18, 2020, 3:43pm UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/19 "2020-03-18T15:43:16Z")
> [@Rakesh\_B](#): > > We have 6 ES data instances each with 7 VCPUs and 62 GIB of RAM, with 23 GIB of HEAP. > > We are using EBS volumes and they are also functioning way below their max capacity I tried to load 3 times FIRST TIME (APM UI failed): ![Screen Shot 2020-03-18 at 8.34.55 AM](https://us1.discourse-cdn.com/elastic/original/3X/9/2/923db0d716cbcf39b0c847583abeff4a850db3f5.png) SECOND TIME (Successfully loaded in the console): ![Screen Shot 2020-03-18 at 8.36.27 AM](https://us1.discourse-cdn.com/elastic/original/3X/8/b/8bb9aecd279c4792b9763091eb978c7b9442fc5f.png) THIRD TIME (partially loaded in the APM UI, errors are not captured in the screenshot): ![Screen Shot 2020-03-18 at 8.38.51 AM](https://us1.discourse-cdn.com/elastic/original/3X/5/8/58a40cf26af4d72d9418e0d920c9d1d9313b87f4.png) FYI: Loading in the Discovery section is the fastest and it never fails ![Screen Shot 2020-03-18 at 8.38.32 AM](https://us1.discourse-cdn.com/elastic/original/3X/c/f/cfd35536229e41569e6d66c97940c4223d9bc5d8.png) ---
**Author:** ![sqren](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sqren/32/26110_2.png) [@sqren](https://discuss.elastic.co/u/sqren)\ **Post date:** [March 18, 2020, 10:54pm UTC](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601/20 "2020-03-18T22:54:08Z")
> FIRST TIME (APM UI failed): Do you see any errors in the Kibana logs or the Chrome Dev tools? [Next page](https://discuss.elastic.co/t/apm-ui-kibana-internal-server-error/223601.md?page=2)