Wachete Not Detecting Changes on an Indian Government Website: Fixes
Check what Wachete captures, whether JavaScript or access restrictions are involved, and whether the right region and alert rule are configured.
If Wachete is not reporting a change on an Indian government website, first inspect the monitor’s preview and latest history: does the captured content include the exact text or region that changed? If not, correct the page selection or try Dynamic monitoring when that content appears only after JavaScript runs. If Wachete shows “Forbidden,” the server may be refusing automated requests; try another monitoring location as a diagnostic step. The available evidence does not establish a general Wachete incompatibility with Indian government websites, so the individual URL and monitor result matter.
Wachete runs monitoring on its servers, so leaving your computer or phone on will not fix a missed check. Its FAQ recommends switching preview to Dynamic, changing the monitoring location, or trying both when content does not load properly. A different location is a diagnostic attempt, not a guaranteed solution. Wachete FAQ
1. Check what the monitor actually sees
- Open the monitor and inspect its latest check, preview, and history. Distinguish the last time Wachete checked the page from the time content last changed; the monitor list may emphasize the latter.
- Compare the captured content with the precise notice, date, table row, or other page region you expected to change.
- If the preview is HTML and you need to inspect visual changes, Wachete documents choosing HTML in the extraction setting, then opening visual differences from monitor details and history.
- If the intended content is absent from the captured value, fix the extraction or selected region before changing notification settings. An alert cannot reliably report a change outside the monitored content.
For API-based workflows, Wachete documents endpoints to retrieve basic monitor information and monitor data, including an option to return differences. Wachete REST API documentation
2. Test whether the page needs Dynamic monitoring
Use Wachete’s preview as the test, rather than guessing based on how modern the site looks:
- Open the page in the current preview mode and check whether the exact content you want is visible.
- Switch the preview to Dynamic and compare. If the content appears only in Dynamic mode, configure the monitor for Dynamic monitoring.
- Run a fresh check and confirm the captured value now includes the target content.
Wachete says most pages can be monitored as static pages, while content rendered by JavaScript should use Dynamic monitoring. Its API uses dynamicContent: true for JavaScript-rendered content. Dynamic mode may take more resources or transfer more data for some pages; Wachete notes that dynamic-page traffic can be high, and proxy costs may depend on transferred data. Check current plan support and costs in Wachete before relying on a specific configuration.
3. Diagnose Forbidden, blank, or incomplete previews
A Forbidden response means the target refused the request; it does not show that the page stayed unchanged. Wachete identifies automated-bot protection as a common reason for Forbidden responses and suggests trying Dynamic preview and changing monitoring location. It also documents rotating residential proxies as an option. Wachete troubleshooting guidance
- Record the response or error shown in preview and when it occurred.
- Try another monitoring location, if available, then check whether preview content changes. Wachete says it can check from several locations worldwide.
- Compare static and Dynamic preview to determine whether rendering is also involved.
- If the site deliberately restricts automated access, ask Wachete support or the site operator about an appropriate access method. Do not assume a proxy will work or that repeated retries will resolve a policy restriction.
If you configure a proxy, verify that it is actually using the intended location. Wachete’s FAQ describes checking the location in preview and configuring a proxy under Profile and the monitor’s advanced HTTP options. A changed location can help diagnose location-dependent behavior, but it does not guarantee access.
4. Verify the selection and notification condition
If the preview contains the right content but no alert arrived, check the monitor’s selected region and notification rule. Wachete supports monitoring a whole page or part of one and documents rules such as text appearing or disappearing. Confirm that the rule matches the change you care about: for example, a changed date is different from text newly appearing.
- Confirm the selected page region contains the changing text.
- Confirm the rule describes the desired event, including whether it watches for a value changing, appearing, or disappearing.
- Check the latest check timestamp and history rather than inferring check timing from the monitor list.
- If using the API, inspect monitor details and returned data or differences to see whether Wachete recorded a changed value.
5. A practical diagnostic sequence
- Capture the evidence: note the exact URL, expected changed content, latest check time, preview result, and any response or error.
- Fix visibility: adjust the selected content or extraction so the preview includes the target.
- Test rendering: compare static and Dynamic preview; use Dynamic if the target appears only there.
- Test access: if the result is Forbidden or blank, try another monitoring location and record the outcome.
- Validate alerts: match the selected region and notification condition to the change, then wait for a subsequent check and inspect history.
- Escalate with details: send Wachete support the URL, mode, preview result, response, latest check time, selected region, and alert rule.
This sequence separates four different problems: the monitor cannot access the page, it cannot render the target, it is watching the wrong content, or it detects the content but the alert condition does not match. The exact URL and latest captured response are needed to identify which one applies.
6. Use a screenshot to inspect the rendered page
A screenshot can help you see what a browser-rendered page looks like at a given moment, especially when a notice or table is visually present but missing from the monitor’s preview. It does not replace Wachete’s history or prove that a change alert rule is configured correctly.
For a local, do-it-yourself capture, open the target URL in your browser after the page finishes loading and save a screenshot. For repeatable captures in a browser automation setup, wait for the relevant content before saving the screenshot; if the target is absent in the rendered browser too, investigate the page’s own loading or access behavior.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a screenshot; use it to inspect what a page renders, not as a replacement for Wachete’s change history. Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed, and response headers report the page verdict and billing status. Its MCP server lets AI agents take screenshots. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Every feature is on every plan. See the ScreenshotNeo site and API documentation.
cURL
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://www.india.gov.in -o shot.webp
Python
import requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://www.india.gov.in"},
timeout=90,
)
open("shot.webp", "wb").write(r.content)
Node.js
const q = new URLSearchParams({
access_key: 'YOUR_API_KEY',
url: 'https://www.india.gov.in'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));
Replace the example URL with the specific public page you need to inspect. Keep your API key private. ScreenshotNeo supports options including full-page capture, waiting for a selector or network idle, custom headers, cookies, user agent, and device presets; see the documentation for parameter names and usage. API parameter names used by other screenshot services also work, which can ease switching.
Sign up for 1,000 free screenshots a month, with no card.
Reliability, performance, and cost considerations
- Check cadence: a change can occur between checks. Compare the last check time with the site’s publication time before concluding the monitor missed a change.
- Dynamic rendering: use it only when preview shows the content requires JavaScript. Dynamic pages can involve more transferred data; proxy providers may charge based on traffic.
- Access restrictions: changing locations can help isolate a location or bot-protection issue, but does not assure access. A persistent refusal needs support or an authorized access path.
- Evidence over repeated retries: preserve the first useful response and preview result. A timestamped record helps distinguish intermittent loading from a stable configuration problem.
- Screenshot limits: a screenshot is a point-in-time visual diagnostic. It does not by itself establish that Wachete’s monitored value changed or that an alert should have fired.
Troubleshooting quick reference
| Symptom | Likely explanation | Next step |
|---|---|---|
| Preview omits the changed notice | Wrong extraction or selected region | Adjust the monitored content and confirm it appears in preview. |
| Content appears only in Dynamic preview | JavaScript renders the target | Enable Dynamic monitoring and verify a fresh check. |
| Forbidden response | Target may block automated requests | Record the response, test another location, and contact support or the site operator if access remains restricted. |
| Preview is blank or incomplete | Rendering or access issue | Compare static and Dynamic preview and test another monitoring location. |
| Preview is right, no notification | Region, alert condition, or notification setup may not match | Review the selected content, rule, notification destination, and history. |
| Monitor list appears stale | List ordering may reflect last change rather than last check | Open monitor details and inspect the latest check timestamp. |
FAQ
Is Wachete broken for Indian government websites?
The available sources do not establish a general India-wide compatibility problem. Diagnose the exact URL using its latest response and preview.
Should I always use Dynamic monitoring for government sites?
No. Test the target content in preview first. Use Dynamic when the content appears only after switching the preview to Dynamic.
Will changing the monitoring location fix Forbidden?
It is a documented diagnostic option, not a guaranteed fix. The site may still restrict automated requests.
Does a screenshot tell me whether Wachete detected a change?
No. It shows a visual page state. Use Wachete’s monitor data and history to determine what it captured and whether its alert condition matched.
Sources
- Wachete FAQ: Forbidden responses, static versus Dynamic preview, monitoring locations, monitor timestamps, and proxy setup.
- Wachete REST API documentation: Dynamic content setting, monitor details, content values, and differences.


