What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Use a browser automation script such as Playwright to open the specific exam result page, wait until its result content is visible, and save a full-page screenshot. Run that script on a schedule with GitHub Actions, cron, or another scheduler. Because each Indian results portal can behave differently—and a scheduled run is not guaranteed to start at an exact time—you’ll need to configure and check the workflow for the portal you choose.
What you need before scheduling a screenshot
- The exact result-page URL. The right portal and page depend on the board or exam; there is no single workflow that fits every Indian result site.
- A stable signal that tells your script the intended content has appeared, such as a result heading, table, or status element. You must identify the relevant selector on the page you use.
- A machine or hosted runner with Node.js and Playwright installed, plus somewhere appropriate to save the screenshot and execution log.
Before automating a public portal, inspect its terms and page flow. Avoid excessive polling: no universal rate limit for Indian result portals is established here. If screenshots contain personal result details, limit access to the files and retain them only as long as needed.
Capture a full-page screenshot with Playwright
Playwright’s screenshot API accepts fullPage: true to capture the scrollable page rather than only the visible viewport. The code below is a runnable starting point; replace the URL and readiness selector with values for the particular portal. Playwright documents page screenshots and full-page capture.
Recommended Free Tools
Install Playwright
- Install Node.js on the machine that will run the capture.
- In a project directory, run
npm init -y, thennpm install playwright. - Install the browser binaries with
npx playwright install chromium. - Save the following as
screenshot.mjs. SetRESULT_URLandREADY_SELECTORin the environment before running it.
import { chromium } from 'playwright';
import { mkdir } from 'node:fs/promises';
const url = process.env.RESULT_URL;
const readySelector = process.env.READY_SELECTOR;
if (!url || !readySelector) {
throw new Error('Set RESULT_URL and READY_SELECTOR for the target portal.');
}
const timestamp = new Date().toISOString().replaceAll(':', '-');
const output = `screenshots/result-${timestamp}.png`;
await mkdir('screenshots', { recursive: true });
const browser = await chromium.launch({ headless: true });
const page = await browser.newPage({ viewport: { width: 1440, height: 1000 } });
try {
await page.goto(url, { waitUntil: 'domcontentloaded', timeout: 60_000 });
await page.locator(readySelector).waitFor({ state: 'visible', timeout: 60_000 });
await page.screenshot({ path: output, fullPage: true });
console.log(`Saved ${output}`);
} finally {
await browser.close();
}
For example, run it with RESULT_URL='https://example.com/results' READY_SELECTOR='h1' node screenshot.mjs, changing both example values to match the real page. The selector is deliberately configurable: a heading might appear before the actual result table, so choose a signal that means the content you need is ready. The Playwright page API documents load-state waits; navigation completing does not by itself prove that a dynamically rendered result is ready. Playwright’s actions generally auto-wait, but that does not replace an explicit, portal-specific readiness condition.
#1 Best Overall
Choose a useful screenshot format and dimensions
The sample writes PNG and uses a 1440-by-1000 viewport before capturing the full page. Playwright also exposes screenshot output and scale options; see its screenshot API. Full-page images can become extremely tall. Inspect the result for legibility and file size, and adjust viewport dimensions or scale if the site’s responsive layout makes the image hard to read. A screenshot records rendered pixels; it is not structured data and does not independently verify that a result is correct.
Schedule the script with GitHub Actions
A hosted runner can launch the capture when your own computer is off. GitHub Actions uses cron syntax for scheduled workflows. Schedules default to UTC, can specify an IANA time zone, and have a documented minimum interval of five minutes. GitHub warns that scheduled runs may be delayed under high load, especially near the start of an hour, and some queued jobs may be dropped. Scheduled workflows run on the repository’s default branch. Check GitHub’s schedule event documentation for current behavior.
Rank #2
- Intuitive interface of a conventional FTP client
- Easy and Reliable FTP Site Maintenance.
- FTP Automation and Synchronization
Add a scheduled workflow
- Commit
screenshot.mjsand the project’spackage.jsonand lockfile to the repository’s default branch. - Create
.github/workflows/result-screenshot.ymlin that repository. - Set the cron expression, portal URL, and readiness selector. The example below runs daily at 02:17 UTC; it is an example schedule, not a recommended universal time.
- Commit the workflow to the default branch. Review the Actions run log and downloaded artifact after the first run.
name: Scheduled result screenshot
on:
schedule:
- cron: '17 2 * * *'
workflow_dispatch:
jobs:
capture:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npx playwright install --with-deps chromium
- name: Capture result page
run: node screenshot.mjs
env:
RESULT_URL: ${{ vars.RESULT_URL }}
READY_SELECTOR: ${{ vars.READY_SELECTOR }}
- name: Keep screenshot and log as an artifact
if: always()
uses: actions/upload-artifact@v4
with:
name: result-screenshot
path: screenshots/
Add RESULT_URL and READY_SELECTOR as repository variables under Settings → Secrets and variables → Actions → Variables. If the target requires credentials, do not place them in the workflow file or public repository; use appropriately restricted secrets and review the portal’s rules before proceeding. The example artifact is an execution record stored by GitHub Actions; choose retention and access settings that suit the sensitivity of the captured page.
In POSIX cron, 17 2 * * * means 02:17 UTC every day when used in GitHub Actions’ default time zone. Pick a cadence based on the exam and portal rather than polling continuously, and avoid minute zero when practical. A schedule requests a run; it does not guarantee capture at the exact wall-clock time. For a time-sensitive result, monitor runs and arrange a fallback instead of treating the scheduled image as guaranteed.
Rank #3
Local cron or hosted runner: which should you use?
| Consideration | Local cron | GitHub Actions |
|---|---|---|
| Runs while your computer is off | No; the machine must be on and available. | Yes, on a hosted runner, subject to scheduling delays or dropped queued jobs documented by GitHub. |
| Schedule and time zone | Depends on the cron service and host configuration. | Cron schedule; UTC by default, with optional IANA time zone and a documented five-minute minimum interval. |
| Missed-run visibility | Depends on the host’s cron logging and monitoring. | Workflow runs and logs are available in Actions, but a delayed or dropped run still requires monitoring and a fallback for time-sensitive use. |
| Browser setup and upkeep | You manage Node.js, Playwright, browser binaries, and updates on your machine. | The workflow installs Node.js and Chromium on its runner; keep the workflow and dependencies maintained. |
| Image storage and access | You choose local storage and its permissions and retention. | The example uploads an Actions artifact; configure retention and access for the captured information. |
| Operating cost | Not stated here; it depends on your existing machine and power use. | Not stated here; check GitHub’s current plan and usage terms for your account. |
Use local cron if you already have a dependable always-on host and want direct control of files. Choose a hosted runner if you do not want to keep your computer running, and add monitoring if missing a run matters.
Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server. Its API takes one GET request with a URL and returns a PNG, JPEG, WebP, or PDF. For an image capture, adapt this cURL call to the result page you intend to capture; API options are documented at ScreenshotNeo’s API documentation.
Rank #4
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/results -o result.webp
ScreenshotNeo removes known consent banners, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and the response identifies page verdict and billing status in headers. Its MCP server offers take_screenshot, get_page_info, and capture_pdf for AI agents and MCP clients. The free plan includes 1,000 screenshots a month without a card; paid plans start at $5 for 3,000 shots. These are ScreenshotNeo plan terms, not a guarantee that a particular portal will be accessible or return the intended result content. Sign up for 1,000 free screenshots a month with no card.
Troubleshooting scheduled captures
- The script errors because a value is missing: Set both
RESULT_URLandREADY_SELECTORin the local environment or repository variables. Check spelling and variable scope. - The readiness wait times out: Inspect the portal manually and identify a selector that appears only when the intended result content is present. The example selector may not match the target page, or the page may not have loaded that content.
- The screenshot is blank or shows a loading state: A navigation event can finish before the result interface renders. Wait for a meaningful visible element and inspect the Actions log and captured image.
- Content below the fold is missing: Confirm the script passes
fullPage: true. Some pages load content as you scroll; inspect the specific portal and adjust the capture approach if needed. - The image is unreadable or enormous: Review the page at the chosen viewport and screenshot scale. Long full-page captures can produce very tall files; adjust dimensions or scale and verify the result remains legible.
- The daily run did not start at the expected time: Confirm the cron time zone and expression, then check the workflow run history. GitHub documents potential schedule delays and dropped queued jobs under high load.
- No artifact was uploaded: Check that the screenshot directory exists and the job reached the artifact step. The sample uses
if: always()so logs and any created files can be retained even when capture fails.
Check the first runs before relying on them
- Run the script manually against the selected page and confirm the intended result content is present.
- Inspect the complete image, including content below the fold, and confirm it is legible at its actual size.
- Trigger the workflow manually with
workflow_dispatch, then review its logs and artifact. - After scheduled runs begin, monitor them and keep a fallback for deadlines where a delayed or missed run would matter.
Frequently Asked Questions
Can I schedule Playwright screenshots to run every day?
Yes. Run the Playwright script from a scheduler such as GitHub Actions or local cron, using a daily schedule and a portal-specific readiness check.
Does a screenshot prove that an exam result is correct?
No. It records what the browser rendered at capture time; it is neither structured result data nor independent verification.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

