Monitor a site protected by HTTP Basic Authentication

Save HTTP credentials for browser and fetch access to a protected site.

Last checked 1 September 2026

Use Username and Password in Advanced Settings only for HTTP Basic Authentication. This browser or command-line authentication challenge is identified by HTTP status 401 and a WWW-Authenticate: Basic response header.

It does not submit HTML forms, complete single sign-on or one-time codes, or preserve an interactive session.

Add the credentials

  1. Add a website, or open its website page and choose the edit action.
  2. Expand Advanced Settings.
  3. Enter the Basic Authentication Username.
  4. Enter the Password.
  5. Select Add website or Save changes.

The username and password can each contain up to 128 characters. A username cannot contain a colon, which separates the credentials. A password requires a username.

Use a dedicated, least-privilege monitoring account. Do not reuse an administrator password. After rotating the credential, update the saved website immediately.

What the credentials cover

TechDash uses the credentials when requesting and rendering monitored pages, so both can pass the same HTTP Basic Authentication prompt.

The settings do not authenticate every website-level lookup. Site Resources fetches for robots.txt, sitemap.xml, llms.txt, and favicon do not use them. A protected resource can fail while authenticated monitored pages work.

If you need a custom assertion on protected content, use a page target such as Head, Body, Content, Headers, Title, or H1 on an authenticated monitored URL. Do not assume that a robots.txt or sitemap.xml custom target receives the Basic Authentication settings.

Use trusted HTTPS

TechDash does not ignore HTTPS certificate errors. The protected site needs a certificate accepted by the monitoring computer. A self-signed, expired, hostname-mismatched, or otherwise invalid certificate can prevent access despite correct credentials.

For protected staging sites, use a valid development certificate or one from your organization's trusted authority.

Protect the saved credential

TechDash protects the password in local app data before storing it, but this does not replace account and disk security. Anyone with access to TechDash data under your user account may still reach locally stored secrets. Protect the computer account.

Troubleshoot access

If a page still returns 401, 403, or an access-denied page:

  1. Verify the username and password outside TechDash against the same HTTPS URL.
  2. Confirm the site uses HTTP Basic Authentication, not a form or proxy sign-in workflow.
  3. Check that the certificate is valid and trusted on this computer.
  4. Check whether the website's hosting or security rules restrict the selected User agent or monitoring computer.
  5. Run the monitored page again and inspect the final URL and HTTP result.

Changing the user agent can change access policy, but it does not bypass authentication or bot protection. Coordinate an explicit allow rule with the site administrator when monitoring traffic is intentionally restricted.

Worked example: monitor a protected staging checkout

Suppose https://staging.example.com/checkout uses HTTP Basic Authentication and must display Sandbox payments enabled. The check matters because a missing banner could let testers mistake staging behavior for production.

Edit the website, expand Advanced Settings, and enter the dedicated monitoring Username and Password. Then add a custom check:

  • Look in: Content
  • Scope: This page
  • Page: the monitored staging checkout URL
  • Match: Is found
  • Value: Sandbox payments enabled
  • Incident level: Warning
  • Notify: Send a notification

A pass means TechDash accessed a usable page and found that case-insensitive literal substring in filtered rendered body text. It does not prove that every staging route is authenticated or that the banner is visually prominent.

For a harmless deliberate failure, keep the valid monitoring credential and temporarily change the custom-check value to a unique phrase that is not on the page, such as techdash-deliberate-test-marker. Select Run now, confirm the custom assertion fails, then restore Sandbox payments enabled and run the page again. This tests matching and recovery without causing an authentication outage or changing the protected site. A real failure happens when credentials rotate without updating TechDash, the account is disabled, or the expected banner disappears.

Authentication and HTTP evidence appears with the monitored page result. If access fails, TechDash may report the HTTP or access problem before optional custom checks run. If access succeeds but the banner is absent, Custom check failed opens at Warning level in this example. A missing staging banner needs prompt investigation but does not normally justify Critical unless it creates documented immediate business, compliance, or access risk. With Notify set to Send a notification, that failure is eligible for allowed desktop and webhook channels.

A benign failure may be a planned credential rotation, maintenance page, redirect, or certificate problem, but it still requires verification. Confirm the same HTTPS URL works with the dedicated credential outside TechDash and that the site uses HTTP Basic Authentication, not a sign-in form.

Correct the credential or page, then select Run now. Verify a successful HTTP result, the expected final URL, and a Good custom result. The relevant incident recovers only after fresh passing evidence; saved Basic Authentication does not apply to separate Site Resources checks.

Related articles