Choose Chrome, TechDash, or a custom user agent

The User agent setting controls the request identity TechDash presents while checking monitored pages. A hosting or security service can use that identity to return different content or block a request.

Change the setting

1. Add a website, or edit an existing website.
2. Expand Advanced Settings.
3. Under User agent, select Chrome, TechDash, or Custom.
4. If you select Custom, enter the exact Custom user agent.
5. Select Add website or Save changes.

Choose Chrome

Chrome is the default. The UI describes it as Chrome for Mac Desktop and TechDash uses its browser-like Chrome identity. This is the best choice for normal monitoring when the site should respond as it does to a typical desktop browser.

Choose it unless the website has a documented reason to identify TechDash differently. Monitoring does not share your everyday browser's cookies, signed-in state, extensions, or personal profile.

Choose TechDash

TechDash uses the explicit crawler identity TechDash/0.1 (+https://techdash.app). Choose it when you want server logs and access rules to identify TechDash monitoring clearly.

This option can be useful when the website administrator has an access rule that explicitly allows TechDash. The administrator should allow only the access needed for monitoring. A user-agent string is self-declared text, not strong authentication, so do not treat it as proof that a request came from a trusted party.

Choose Custom

Custom sends the exact trimmed user-agent string you enter. The value must be 4-256 characters and contain only printable ASCII characters.

Use a custom value only for a documented access, routing, or testing requirement, such as an approved internal monitor identity for staging.

Do not include a password, API key, session token, email address, or other secret in the user-agent string. User agents can be stored in website, hosting, analytics, and security logs. The field is an identity label, not a secure credential channel.

Do not use Custom to claim that TechDash is Googlebot or another crawler. Changing text does not reproduce that crawler's network identity, rendering behavior, request patterns, or verification method. It can also produce misleading monitoring results and violate an access policy.

Understand what the setting affects

The selected user agent applies to monitored page requests and rendered responses used by page custom checks. A site can return different HTML, headers, status codes, or challenges for different identities. Changing it can open or recover incidents without a page-code change.

The setting does not bypass HTTP Basic Authentication, a website security challenge, IP restrictions, or a sign-in form. Configure Username and Password separately for HTTP Basic Authentication.

The current website-level Site Resources fetches are separate from monitored page crawling and do not use the website's selected user agent. Do not rely on a custom user agent to gain access to protected robots.txt or sitemap.xml resource checks.

Verify after changing it

Run representative monitored pages after saving. Include pages behind different templates or access rules. Confirm the HTTP result, final URL, rendered content, and any custom-check outcomes.

If a page fails only with one identity, ask the website administrator to review website and security logs for that exact user agent. Prefer a documented access rule over repeatedly changing the string to imitate browsers or crawlers.

Worked example: verify an approved monitoring identity

Suppose a staging site allows requests labeled Acme-QA-Monitor/1.0, and its checkout page must show Test payments only. The identity matters because an unapproved request receives an access-denied page instead of the staging application.

Edit the website and choose Custom under User agent, enter Acme-QA-Monitor/1.0, and save. Add a custom check for the monitored checkout URL:

• Look in: Content
• Scope: This page
• Match: Is found
• Value: Test payments only
• Incident level: Warning
• Notify: Send a notification

A pass means TechDash received a usable rendered page whose filtered content contains that case-insensitive literal substring. It supports the conclusion that the chosen identity reached the expected page, but it does not authenticate TechDash or prove every protected route is available.

For a deliberate failure, change the user agent to an unapproved value agreed with the site administrator, save, and select Run now for the checkout page. Restore the approved value immediately after the test. A real failure can happen when a security rule changes and the approved identity starts receiving an access-denied page or different content.

The HTTP and custom-check evidence appears with the monitored page's latest result. If the page is usable but the phrase is absent, TechDash opens Custom check failed at Warning level. If access fails earlier, an HTTP or access incident may appear and the optional custom check may be skipped. With Notify set to Send a notification, a custom-check failure is eligible for allowed channels.

A benign difference can come from consent, personalization, a redirect, or a temporary security challenge. Verify the final URL, HTTP result, response content, and the exact user agent in the administrator's logs. After correcting the access rule or restoring the approved identity, select Run now. A fresh passing page result recovers the relevant incident; verify representative pages because one pass does not prove the rule works everywhere.

Related articles

• Monitor a site protected by HTTP Basic Authentication
• Use Web Bot Auth with Shopify
• Understand crawl access and raw-versus-rendered checks
• Troubleshoot a custom check that fails unexpectedly