on
10 Jan 2025
11:45 AM
- edited on
22 Jan 2026
07:09 PM
by
Adam-Piotrowicz
This article will review the most common problems and questions related to the Dynatrace Mobile App, which customers can download to check the problems their environment reports.
This is most likely due to a permission issue. In order to solve this, try adding the role "Manage support tickets" and try to log in again. If it is not possible to perform this due to a security perspective, please contact the support team.
If a firewall is being used, it must allow incoming traffic to the Cluster ActiveGate through the designated port. Double-check that the domain name has a valid SSL certificate. Use the Digicert Checker page to verify that.
Also, it is essential to consider that when executing a curl:
curl -v https://<Your_domain>:<port>/rest/health
It would be needed to see the following header:
Also, another command that is recommended to execute is the following:
curl -v -X GET -H "x-dynatrace: MT_3_20_1272745774_1-0_96fbc5f7-6801-4f55-ac46-18d8eab7b97e_0_1234_71" -H "Content-Type: application/json" -H "User-Agent: okhttp/4.11.0" -H "Accept: application/json" -H "Authorization: API-Token <TOKEN>" https://<URL domanin>:<port>/e/<env uuid>/api/v2/problems?pageSize=1
The output, if everything is fine, should look like:
curl -vvv -k -X 'GET' 'https://<AG URL>:9999/e/<ENV ID>/api/v2/problems' -H 'accept: application/json; charset=utf-8'
Note: Unnecessary use of -X or --request, GET is already inferred.
* Trying xxx.xxx.xxx.xxx:9999...
* Connected to xxxxxxxxxxxx (xxx.xxx.xxx.xxx) port 9999
* ALPN: curl offers http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
* subject: CN=xxxxxxxxxxxx
* start date: May 3 09:13:56 2025 GMT
* expire date: Aug 1 09:13:55 2025 GMT
* issuer: C=US; O=Let's Encrypt; CN=R11
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* using HTTP/1.x
> GET /e/<ENV ID>/api/v2/problems HTTP/1.1
> Host: xxxxxxxxxxxx:9999
> User-Agent: curl/8.4.0
> accept: application/json; charset=utf-8
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 401 Unauthorized
< Date: Tue, 10 Jun 2025 10:28:57 GMT
< Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
< Vary: Accept-Encoding
< Content-Type: application/json;charset=utf-8
< Cache-Control: no-store, no-cache
< Pragma: no-cache
< Dynatrace-Response-Source: Cluster
< X-Robots-Tag: noindex
< Server: ruxit gateway
< Content-Length: 67
<
* Connection #0 to host xxxxxxxxxxxx left intact
{"error":{"code":401,"message":"Missing authorization parameter."}}
Once you have executed such a command, if the curl doesn't work correctly, you might have different problems, such as a blocked port, VPN-related problems, or other general network problems. Remember that the URL that you set up in the cluster has to be publicly available.
Please check that you have the role "view environment" for the user. Also, setting up mobile phones for the same user multiple times with different QR codes invalidates old ones. If you want to associate multiple phones with the same user, they would need to use the same QR code.
For the app to work correctly, it will need to access data from the cluster in some manner. This will require, at a minimum, cluster communication with Mission Control and an accessible ActiveGate. Without Mission Control access, the cluster can’t send notification information to the app through Mission Control.
In this case, ensure to have one Cluster ActiveGate, whose purpose is to route traffic. If there is already one, and it looks like the picture below, it would be the wrong one.
When installing a Cluster ActiveGate, it would be needed to select the following option:
The dashboard cannot be seen via the Dynatrace Mobile App. It is meant only for problem notifications.
It is possible to see those MZs sticking to the problems the app is fetching. If there is only one problem in the last two hours, and the problem belongs to MZ: A, but the environment has 150 MZs overall, then the filter will only offer MZ: A and not 150 MZs.
The authentication mechanism can be an API key or OAuth 2.0, depending on the specific requirements and configuration.
This is via the Public REST API through HTTPS and OAuth ( for SaaS customers ) or API token auth ( for Managed customers ).
The update is performed via the app store.
The Dynatrace Mobile Application does not support OTP.
For Saas
https://docs.dynatrace.com/docs/analyze-explore-automate/notifications-and-alerting/push-notificatio...
For Managed
https://docs.dynatrace.com/managed/analyze-explore-automate/notifications-and-alerting/push-notifica...
If you still experience issues with your Dynatrace Mobile Application after reading these frequently asked questions, please open a support case and share as much information as possible, including all the detailed steps you have already performed.
If, after reading this article, the Dynatrace Mobile App is still dealing with some issues, please open a support ticket explaining all the troubleshooting steps that have been done already, like:
Currently the MobileApp is built around ManagementZones. However all the new applications (including the new Problems app) are build around the grail permissions, utilizing the "dt.security_context". When will the mobileApp be adjusted to also work with grail based permissions?