How to Monitor a Password-Protected Page with Fluxguard

To monitor a password-protected page with Fluxguard, add the login page to a session, configure the login actions or basic-auth credentials, then run a crawl and inspect the capture to confirm Fluxguard reached the authenticated page. For a standard login form, configure the username field, password field, and submit action. For a browser-style basic-auth prompt, enter credentials in Session Settings under the Crawl tab. Use this only for sites you own or are authorized to access.

1. Identify how the site authenticates

First determine what appears when you open the page in a fresh, signed-out browser:

What you see	Fluxguard setup
A page with username and password fields	Add the login URL, crawl it once, then configure actions for the username field, password field, and submit button.
A browser-style username/password prompt for HTTP Basic Authentication	Enter the authentication details in Session Settings under the Crawl tab.
A login followed by additional buttons, selections, or form submissions	Configure the needed form, click, selection, or JavaScript actions in sequence, then validate the resulting capture.

These methods are different. A standard web form is configured through page actions; basic authentication is configured in the session settings. Fluxguard’s [official tutorial](https://fluxguard.com/how-to-guides/monitor-changes-behind-logins/) covers both and says to use the product only to log in to your own sites or sites where you have permission.

2. Configure a standard web-form login

1. Add the login URL. Use the URL where the sign-in form is presented, not only the protected destination URL.
2. Run an initial crawl. This gives Fluxguard the login page so you can configure actions against its fields and controls.
3. Set the username action. Identify the username or email field and configure the action to enter the account name.
4. Set the password action. Identify the password field and configure it to enter the password.
5. Submit the form. Configure an action for the submit button. If authentication requires another step, add the necessary action(s) for that workflow.
6. Allow the page to settle. If the site loads slowly after submission, adjust the wait before capture. Fluxguard’s tutorial gives 6,000 milliseconds as an example, not a universal or guaranteed setting.
7. Restart the crawl and inspect the result. Check the screenshot or thumbnail. It should show the intended signed-in content, rather than the login form, an error, or an intermediate loading state.

Keep the action sequence limited to the steps needed to reach the state you want to monitor. Login pages vary, so field selectors, extra verification steps, and timing must be validated for the particular site.

3. Configure HTTP Basic Authentication

1. Open the session’s settings.
2. Go to the Crawl tab.
3. Enter the authentication details for the browser-style basic-auth prompt.
4. Restart the crawl and confirm the captured page is the authenticated content.

Do not enter these credentials as form-field actions unless the site actually presents a web form. Fluxguard’s tutorial notes that readers who do not recognize the basic-auth prompt can generally ignore that configuration.

4. Monitor more than one page in the authenticated session

When the workflow needs several protected pages, append those URLs after the login page in the same session. Fluxguard documents that pages added after login can use session state preserved across pages, including cookies and local storage. Add only pages the authenticated workflow can reach and that you are authorized to monitor.

In the documented sequence, adding the login page again can let the session capture both the login page and the page shown after authentication. Verify the resulting screenshots so you know which state each monitored URL represents.

5. Validate the capture and adjust the workflow

• Confirm the account state: look for a recognizable element from the signed-in page, not merely a successful page load.
• Check the intended destination: redirects may land on a dashboard or intermediate page instead of the content you meant to monitor.
• Settle asynchronous content: if the page is still loading after submit, increase the wait and crawl again. Choose a wait based on the page’s behavior; the tutorial’s 6,000 ms value is an example only.
• Reproduce required interactions: if content only appears after a click, selection, or second submission, configure that action as well.
• Review after site changes: a changed form or workflow can invalidate configured actions, so inspect captures when monitoring stops showing the expected state.

6. Troubleshooting

Symptom	Likely cause	What to do
The screenshot still shows the login form	The username/password actions or submit action did not run successfully, or the session did not authenticate.	Check the configured fields and submit control, then restart the crawl and inspect the result.
The screenshot shows a loading screen or incomplete page	The site needs more time after form submission or renders content asynchronously.	Increase the post-submit wait and crawl again. Treat 6,000 ms as an example, not a required value.
The capture shows an error or unexpected destination	The login flow may require another step, or a redirect may have changed the destination.	Review the workflow and add only the required form, click, selection, or JavaScript action. Confirm the final captured URL/state.
Basic-auth content remains inaccessible	The site may use a standard web form, or the credentials may not be configured in the session’s Crawl settings.	Identify the authentication prompt type, then use the matching configuration path.
Some protected pages work but others do not	Pages may require extra interactions or a different authenticated state.	Keep related pages in the same session where appropriate, reproduce the required steps, and validate each page’s capture.
The captured state changes between crawls	The site may show session-dependent or time-dependent content, or the authentication flow may have changed.	Compare the captures, check whether the login still completes, and update the actions or wait when the site workflow has changed.

7. Plan, usage, and operating considerations

Fluxguard’s pricing page currently lists Standard (Periscope) at $110 per month and includes Form Submission Tracking for changes behind logins and gated content. It lists a seven-day free trial for paid plans. Pricing, plan names, features, and trial terms can change, so check the [current pricing page](https://app.fluxguard.com/pricing) before choosing a plan.

Estimate monitoring usage from the number of pages and crawl frequency you need. Fluxguard says its displayed site-count estimates assume about ten pages crawled once daily, and actual credit use varies. Its FAQ says each crawled page deducts one credit; optional AI summaries, translation, and enhanced proxy use additional credits. Calculate against your own page count, schedule, and selected options rather than treating the displayed estimate as a guarantee. See the [Fluxguard FAQ](https://fluxguard.com/faq/).

For reliability, periodically inspect captures, especially after changing the monitored site’s login flow. A recurring monitor is useful only while the configured actions continue to reach the intended page. For performance and cost, keep the monitored set focused on pages whose changes matter and choose a crawl frequency that matches how quickly you need to learn about changes.

Or skip the browser setup

If your goal is to capture a page rather than monitor recurring changes behind a login, [ScreenshotNeo](https://screenshotneo.com) provides a website screenshot API and MCP server. A single GET request returns PNG, JPEG, WebP, or PDF. It does not replace Fluxguard’s recurring authenticated monitoring workflow.

See the [ScreenshotNeo API documentation](https://screenshotneo.com/docs/) for configuration and options. Here is the one-call cURL example:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. These are individual captures, not a recurring login-monitoring service.

Sign up for 1,000 free screenshots a month, no card required.

FAQ

Can Fluxguard monitor a page I cannot log into?

No. The configured session must be able to reach the authenticated state. Use only accounts and sites you own or have permission to access.

Is the 6,000-millisecond wait required?

No. It is an example in Fluxguard’s tutorial. Settle time depends on how quickly the target site completes its login and renders the content.

Can I monitor content revealed by a form after login?

Yes, if you configure the necessary form actions and validate that the capture reaches the resulting content. Fluxguard’s setup tutorials also cover clicks, selections, and JavaScript actions.

Does ScreenshotNeo monitor changes over time?

The described ScreenshotNeo endpoint returns a screenshot or PDF from a GET request. For recurring monitoring of authenticated pages, follow the Fluxguard workflow above.