How to Set Up Transaction Monitoring in Pingdom

An uptime check can tell you that a page returns an HTTP response. It cannot prove that a user can log in, search, submit a form, or complete another browser workflow. Pingdom Transaction Monitoring addresses that gap by replaying a scripted user journey at a schedule and reporting which step fails.

The difficult part is not adding many commands. It is creating a small, deterministic transaction that survives harmless interface changes and fails when the business workflow is genuinely broken.

This tutorial uses Pingdom's Transaction Check Editor approach because it exposes the logic clearly: navigate, interact with elements, wait for state changes, and validate a meaningful outcome. It also explains stable selectors, timing, diagnostics, and current limitations.

Last verified: September 10, 2026. SolarWinds documentation warns that navigation may differ when the APM Integrated Experience is enabled. Some examples and screenshots in the official corpus are older, so this guide relies on current documented capabilities rather than treating historical screenshots as authoritative UI.

What You'll Accomplish

You will create a transaction check that:

1. models one critical browser journey;
2. uses stable element selectors;
3. waits for application state rather than relying mainly on arbitrary sleeps;
4. validates the final outcome;
5. runs successfully from a selected region;
6. exposes useful failure screenshots/details when a step breaks; and
7. avoids known limitations such as switching between browser tabs/windows.

Prerequisites

Prepare:

• a Pingdom account with Transaction Monitoring available;
• a stable website or non-destructive user workflow;
• a dedicated test account if authentication is required;
• stable test data that can be reused without harming production;
• permission to run synthetic browser traffic against the target service; and
• knowledge of the outcome that proves the transaction succeeded.

Do not use a transaction that purchases a real item, sends a real customer message, changes production permissions, or performs another destructive action on every scheduled run.

Quick Answer

Open Pingdom's Transaction monitoring area and add a check. Give it a descriptive name, choose a schedule and test region, then use the Check Editor to model the shortest critical path. Start with Go to URL, interact with elements using stable CSS selectors, add Wait for element before actions that depend on a page or component loading, and finish with a validation such as an expected URL or expected text/element. Run the test before enabling alerts. If a step fails, inspect Pingdom's error details and available screenshot. Avoid brittle generated selectors and avoid fixed Sleep commands when you can wait for a specific element or state instead.

Step 1: Pick One Critical User Journey

A transaction monitor should answer a business-oriented question such as:

• Can a test user log in?
• Can a visitor search for a known item?
• Can an account page load after authentication?
• Can a customer add a test item to a non-destructive cart?
• Can a form reach a known confirmation state without sending a real request to a third party?

Do not combine all of those into one check.

A short flow gives you:

• clearer failures;
• fewer selector dependencies;
• faster execution;
• easier maintenance; and
• less synthetic traffic.

For this tutorial, imagine a generic search workflow:

1. load /search;
2. wait for the search input;
3. enter a known harmless term;
4. submit;
5. wait for the results container; and
6. verify a known result marker.

The exact selectors must come from your application. Do not copy the selectors from an unrelated example.

Step 2: Create the Transaction Check

The current SolarWinds getting-started documentation describes the path as:

Monitoring → Transaction → Add check

Your account may use different navigation under the APM Integrated Experience. If so, locate the Transaction Monitoring product area rather than trying to reproduce an old screenshot exactly.

Configure:

• a descriptive check name;
• the execution interval available for your account; and
• the region from which the transaction should run.

SolarWinds' documented example lists four transaction regions: US East, US West, Europe, and Australia. Availability can change, so choose from what your current account presents.

Name the check after the outcome, not the implementation:

Customer portal - test user can sign in

is more useful than:

Transaction script 3.

Step 3: Start with Go to URL

The first action is normally Go to URL.

Use the canonical HTTPS page where the workflow starts.

For example:

https://example.com/search

The domain is intentionally generic. Replace it with your own approved test target.

If the application redirects from /search to a login screen or another domain, decide whether that redirect is part of the expected journey. Unexpected cross-domain authentication flows can make the transaction more fragile and may require a different monitoring approach.

Step 4: Use Stable Selectors

Pingdom transaction actions rely heavily on selectors that identify page elements.

A fragile selector might encode presentation structure:

body > div:nth-child(2) > div > form > input:nth-child(1)

A stronger application-controlled selector would be something like:

#search-input

or a stable dedicated data attribute if the editor/current selector support allows it.

The exact syntax must be supported by Pingdom's editor and your page.

Prefer selectors your application owns

Good selector qualities:

• unique;
• semantically tied to the element;
• unlikely to change because of CSS layout;
• consistent across deployments; and
• not generated randomly by a front-end framework.

When possible, ask the front-end team to preserve monitoring/test selectors as part of the application's interface contract.

Do not blindly copy "Copy selector"

Browser developer tools can produce a valid selector that is still brittle. It may depend on DOM position or generated classes.

Use the browser's selector tools to inspect the page, then simplify the selector to the smallest stable identifier.

Step 5: Wait for Elements Instead of Racing the Page

One of the most useful recommendations in SolarWinds' current Transaction Check Tips & Tricks is Wait for element.

Synthetic commands execute quickly. After clicking a link or submitting a form, the next page/component may not yet be ready.

A brittle flow might be:

1. click Login;
2. immediately fill #username.

A more reliable flow is:

1. click Login;
2. wait for #username to exist;
3. fill #username.

This ties the next action to observable application state.

Use Sleep only as a fallback

Pingdom also supports a generic Sleep command.

A fixed sleep can occasionally be necessary when there is no stable element or state to wait for, but it has tradeoffs:

• too short causes intermittent failures;
• too long increases execution time; and
• it does not prove the page is actually ready.

Prefer an explicit element/state wait whenever the workflow exposes one.

Step 6: Fill and Submit the Form

Use the editor's action appropriate to your application:

• Fill in field;
• Select dropdown;
• Click element/button;
• Submit form; or
• another currently supported command.

For a generic search example, the conceptual script is:

Go to URL https://example.com/search
Wait for element #search-input to exist
Fill in field #search-input with synthetic-monitor-test
Submit form #search-form

This is an illustrative structure, not a command block proven against your site. Replace every URL, selector, and value with ones validated in Pingdom's current editor.

Use dedicated test credentials

For authenticated flows:

• create a dedicated synthetic-monitor user;
• grant only the permissions the workflow needs;
• prevent that account from accessing sensitive administrative actions;
• avoid publishing its credentials; and
• coordinate password/token rotation with monitoring.

Do not embed an employee's personal login in a scheduled synthetic check.

Step 7: Validate a Meaningful Outcome

Actions prove that Pingdom attempted the flow. Validations prove the flow achieved the intended outcome.

SolarWinds documents validation patterns such as:

• expected URL; and
• waiting for an element to contain expected text.

For the generic search example, a final validation might conceptually be:

Wait for element #search-results to exist
Wait for element #search-results to contain synthetic-monitor-test

Choose a stable success marker.

Avoid validating:

• a rotating marketing headline;
• a timestamp that changes every run;
• personalized content;
• an element that loads independently of the business operation; or
• an implementation detail unrelated to user success.

A transaction should fail because the user journey is broken, not because the homepage copy changed.

Step 8: Run Test and Inspect the Result

The current getting-started documentation tells users to run the transaction from the editor with Run Test.

Do this before enabling production alerts.

A successful run validates the current script from the selected test environment.

A failed run is often more useful during setup because it reveals which assumption is wrong.

Use failure screenshots carefully

SolarWinds documentation states that a failed transaction step can expose a screenshot through the error details. It also notes that these screenshots are not retained indefinitely and are primarily diagnostic.

Inspect:

• whether the expected element exists;
• whether a modal/banner obscures it;
• whether the application redirected;
• whether authentication failed;
• whether content loaded too slowly; and
• whether the selector refers to a previous version of the page.

Be careful with screenshots of authenticated applications. They can contain names, email addresses, internal URLs, or other sensitive data.

Step 9: Understand Important Pingdom Limitations

No switching between browser windows or tabs

Current Pingdom transaction documentation states that a transaction check cannot switch between browser windows/tabs. It can continue through links/buttons that navigate within the active tab/window.

This can affect:

• payment-provider flows;
• OAuth login;
• support portals;
• documents that open in a new tab; and
• applications relying on popups.

If your journey inherently requires multiple windows, redesign the synthetic path if possible or choose a monitoring system that supports the needed behavior.

Hover behavior is limited

The tips documentation also explains that the synthetic bot does not have a normal mouse cursor, so hover-specific interactions can be problematic.

Do not make monitoring depend on UI behavior that is not supported by the synthetic engine.

Transaction checks are browser traffic

Unlike the simple uptime HTTP check, transaction checks use a browser-style execution model and can trigger web analytics. SolarWinds documents that Pingdom transaction traffic can appear in analytics and suggests filtering known synthetic traffic when appropriate.

Do not confuse synthetic sessions with real-user conversion data.

Step 10: Configure Alerts After the Script Is Stable

Only enable disruptive notifications after the transaction runs reliably.

Choose:

• the service owner;
• an appropriate notification channel;
• a failure-confirmation approach;
• recovery behavior; and
• a runbook.

A transaction with unstable selectors can create far more alert noise than a simple uptime check. Fix the test before weakening the alert.

Verify the Setup

A finished transaction monitor should pass this checklist:

• the journey represents one meaningful user outcome;
• the test account and data are safe for repeated execution;
• selectors are stable and application-controlled where possible;
• waits depend on observable state rather than mostly on fixed sleeps;
• the final step validates a meaningful result;
• Run Test succeeds;
• scheduled runs succeed repeatedly;
• alerts go only to the intended responders; and
• responders know where to find failure details/screenshots.

Controlled failure validation

To prove that the monitor fails for the right reason, use a test or staging environment when possible.

Change a harmless expected value or use a deliberately invalid selector in a cloned/non-production check. Run the test and confirm that Pingdom identifies the expected failing step.

Then restore the valid transaction before enabling normal alerts.

This is a recommended validation method, not a claim that PerfMonitoring ran a live Pingdom transaction.

Common Problems and Fixes

Problem: The transaction fails intermittently after navigation

Cause: the next action runs before the new page/component is ready.

Fix: add Wait for element on a stable element that proves the next state has loaded. Use Sleep only if no observable state exists.

Problem: A selector works today and breaks after a UI release

Cause: the selector depends on DOM position, generated classes, or presentation structure.

Fix: use a stable ID or application-supported test selector. Make synthetic selectors part of front-end change review.

Problem: Login opens a new window

Cause: the workflow requires a capability Pingdom transaction checks currently do not support.

Fix: use an authentication path that remains in the current tab if the application supports one, or choose another synthetic approach for that journey.

Problem: The screenshot shows the element, but the script cannot find it

Cause: the selector may be wrong, the element may be inside a different dynamic state, or timing may differ from what the screenshot suggests.

Fix: inspect the element in browser developer tools, simplify the selector, add a state-based wait, and rerun the editor test.

Problem: Consent or chat banners block a button

Cause: synthetic sessions receive a modal/banner that your manual test did not.

Fix: make the test environment deterministic. If the banner is part of the user experience, include a supported non-destructive dismissal step. Do not hide a real user-blocking problem just to make monitoring pass.

Problem: Analytics shows synthetic conversions

Cause: transaction checks run browser traffic that can trigger analytics.

Fix: identify and filter synthetic sessions using current Pingdom/analytics guidance while preserving separate evidence of the synthetic monitor itself.

Problem: The workflow exceeds practical execution time

Cause: the transaction includes too many pages, arbitrary sleeps, or unnecessary operations.

Fix: monitor the shortest critical path. Split unrelated journeys into separate checks so each failure is actionable.

Best Practices

Prefer a deterministic test account

Do not let other people use the same account manually. Keep its data stable and reset it when the application requires state changes.

Make synthetic selectors part of your UI contract

If engineering teams know that #synthetic-login-submit is used by monitoring, they can avoid removing it accidentally or can update the monitor alongside the application.

Keep the journey short

Every extra click, animation, third-party resource, and page transition increases failure surface. Monitor the minimum path that demonstrates the business outcome.

Validate the outcome, not just the navigation

A transaction that only clicks through pages can remain green even if the expected result is wrong. Include a final assertion tied to user success.

Separate third-party failures where practical

If a checkout depends on an external payment provider, decide whether your transaction should test that provider. Avoid repeatedly performing real financial actions.

Review transactions after front-end deployments

Transaction checks are intentionally sensitive to user-visible workflows. A successful deployment can still change selectors, routes, timing, or authentication behavior enough to break a synthetic script.

When This Setup Makes Sense

Pingdom Transaction Monitoring is useful when HTTP availability is not enough and success requires a browser workflow.

Examples include:

• login;
• account navigation;
• product/search result validation;
• non-destructive cart behavior;
• form workflow; and
• authenticated page availability.

Use a basic uptime check when the success condition is only endpoint reachability/status. Simpler checks are cheaper to maintain and easier to diagnose.

FAQ

Should I use Sleep or Wait for element in Pingdom transactions?

Prefer Wait for element when a specific DOM state indicates readiness. A fixed Sleep waits for time, not success, so it can be both slower and less reliable.

Can Pingdom transaction checks switch browser tabs?

Current SolarWinds documentation says no. The check can navigate through the current tab/window but cannot switch to another browser window or tab.

How do I make Pingdom selectors less brittle?

Prefer unique IDs or dedicated stable test selectors over long DOM-position selectors or generated class names. Validate the selector in the Pingdom editor after application changes.

Why did a transaction break after a harmless front-end release?

A front-end change can alter DOM structure, element IDs/classes, loading timing, redirects, or banners without breaking the feature for a human. Inspect the failing step/screenshot and update the synthetic contract where appropriate.

Is the Web Transaction Recorder the same as the Check Editor?

No. SolarWinds also documents a separate Web Transaction Recorder workflow. Recordings created there are edited in the recorder, while checks created in My Pingdom are edited in My Pingdom. This tutorial intentionally focuses on the Check Editor path.

Conclusion

Reliable transaction monitoring depends on deliberate scope more than script length. Pick one critical user journey, use stable selectors, wait for observable state, validate a meaningful outcome, and run the test repeatedly before paging production responders.

When the transaction fails, use Pingdom's step-level diagnostics and screenshots to distinguish an application failure from a brittle selector or timing assumption. Keep the monitor aligned with the user journey as the front end evolves.

For simple endpoint availability, use the sibling tutorial How to Set Up a Pingdom Uptime Check instead.

References

1. SolarWinds Pingdom Documentation — "Set up transaction monitoring" — SolarWinds — https://documentation.solarwinds.com/en/success_center/pingdom/content/gsg/set-up-transaction-monitoring.htm — accessed September 10, 2026.
2. SolarWinds Pingdom Documentation — "Transaction Checks" — SolarWinds — https://documentation.solarwinds.com/en/success_center/pingdom/content/topics/transaction-checks.htm — accessed September 10, 2026.
3. SolarWinds Pingdom Documentation — "Transaction Check Tips & Tricks" — SolarWinds — https://documentation.solarwinds.com/en/success_center/pingdom/content/topics/transaction-check-tips-tricks.htm — accessed September 10, 2026.
4. SolarWinds Pingdom Documentation — "Transaction Recorder" — SolarWinds — https://documentation.solarwinds.com/en/success_center/pingdom/content/topics/transaction-recorder.htm — accessed September 10, 2026.
5. SolarWinds Pingdom Documentation — "Google Analytics and Pingdom" — SolarWinds — https://documentation.solarwinds.com/en/success_center/pingdom/content/topics/google-analytics-and-pingdom.htm — accessed September 10, 2026.