How to Schedule Website Screenshots with Loki

To schedule website screenshots with Loki, configure your CI provider to run a workflow on a recurring schedule. In that workflow, build or serve Storybook, then run Loki in test mode against saved reference screenshots. Loki captures Storybook views and compares them with those references; the reviewed Loki documentation does not describe a built-in time scheduler or specify schedule syntax for a particular CI provider. Loki’s CI guide shows the build-and-test pattern.

What the scheduled job does

Loki is intended for visual regression testing of Storybook. A scheduled run is useful for checking whether components render differently in a known environment over time, or for detecting changes introduced by dependencies, assets, or application code. It does not replace an uptime monitor for arbitrary live websites: the documented workflow runs Loki against Storybook.

The CI scheduler starts the workflow; Loki does the screenshot capture and comparison. The job needs a usable Storybook build or server and a set of reference images. A test run should report unexpected visual differences for review. Do not make it silently update or approve the references, because that would accept changes without review.

Prepare Loki and reference screenshots

Make Storybook available. Decide whether the job will build Storybook into static files or start a server. Loki does not start Storybook for you.
Create initial references. Use Loki’s reference update workflow, then review and commit the expected baseline images. Consult the current getting-started guide for the commands appropriate to your project.
Keep references accessible to CI. Usually this means versioning them with the project so the scheduled job compares against the same approved baseline.
Choose a stable test environment. Keep the Storybook build, browser target, and relevant configuration consistent between runs where possible. Loki’s repository documents multiple execution targets, so check its current documentation for compatibility and setup details.

Run Loki in a scheduled CI workflow

The following shell steps show the core CI sequence from Loki’s documented static Storybook example. Add them to a workflow configured with your provider’s scheduler. The exact scheduler configuration, permissions, and recurrence limits depend on that provider and are not specified by Loki’s documentation.

npm ci
npm run build-storybook
npx loki --requireReference --reactUri file:./storybook-static

--requireReference makes the run fail if a required reference image is missing. --reactUri file:./storybook-static points Loki at the static build output. Use the URI form and build command that match your Storybook project and installed Loki version; see the official CI example.

In your CI provider, create a recurring workflow trigger and, if useful, retain a manual trigger for investigating a change. Put the build and Loki test steps in the workflow job. If Storybook is served instead of built as static files, start the server in the job and point Loki at the reachable Storybook URI. Ensure the server is ready before Loki starts.

Review current screenshots and differences

Loki’s CLI documentation lists these default output locations:

Directory	Purpose
`./.loki/reference`	Approved baseline screenshots used for comparison.
`./.loki/current`	Screenshots captured by the current run.
`./.loki/difference`	Images showing differences between current captures and references.

When a scheduled run fails, inspect the difference output and the current captures. If a visual change is intended, update the references using Loki’s update or approval workflow and review the resulting baseline changes before committing them. Keep test runs in test mode; do not use a scheduled job to approve its own changes. See the CLI documentation and getting-started guide for reference management.

Configure recurrence and CI artifacts

Set the recurrence in your CI provider’s workflow scheduler, not in Loki. Check the provider’s current documentation for its schedule format, timezone behavior, minimum interval, branch rules, and whether scheduled runs can be manually started. The reviewed Loki sources establish CI usage but do not establish these provider-specific details.

If your CI provider supports artifacts, save the current screenshots and difference images when a run fails. This gives reviewers the evidence needed to diagnose a change even if the job workspace is removed. Loki specifies the output directories, but artifact upload and retention are controlled by your provider.

Options and environment choices

Static build or server: The documented CI pattern builds static Storybook and supplies its local directory URI. A running server is another possible setup when the job can reliably start and reach it.
Reference enforcement: Use --requireReference when missing baselines should fail rather than allow an incomplete comparison.
Execution target: Loki’s repository lists Chrome in Docker, Chrome in AWS Lambda, local Chrome, and iOS and Android simulators among its targets. Availability and configuration can change; consult the current project documentation before choosing a target.
Reference updates: Loki has separate test, update, and approve commands. Use test for recurring checks; reserve reference changes for reviewed updates.
Output locations: The CLI documents default reference, current, and difference directories. Check the current CLI help or documentation if you need to configure paths or other command options.

Troubleshooting

Symptom	Likely cause	What to check
Storybook cannot be opened	The build path or URI is wrong, or the server is not running or ready.	Confirm the build output exists in the job, the URI points to it, or wait for the server to become reachable before starting Loki.
The run fails because a reference is missing	`--requireReference` is enabled but no baseline exists for a captured view.	Generate and review the needed reference with Loki’s update workflow, then commit it so scheduled CI can access it.
Unexpected difference images appear	The rendered Storybook output changed, or the capture environment differs from the baseline environment.	Compare current and reference images; check application changes, fonts and assets, browser target, and environment consistency. Approve a new baseline only if the change is intended.
Local runs pass but scheduled runs fail	CI may have different dependencies, browser setup, environment variables, or access to assets.	Use the same lockfile and build steps, verify CI has required configuration and network access, and capture the CI output as an artifact when possible.
The workflow never runs at the expected time	The schedule is configured incorrectly or provider policies affect scheduled triggers.	Check the CI provider’s current scheduler documentation for timezone, branch, interval, and repository activity requirements.
Differences are accepted without review	The workflow is running a reference update or approval command instead of a test.	Run Loki’s test command for scheduled checks. Make baseline updates a separate, deliberate review step.

Performance, reliability, and cost

Run duration depends on the size of Storybook, number of stories being captured, and the selected browser or simulator environment. The reviewed Loki sources provide no benchmark or fixed runtime figure. Keep the scheduled suite focused on the stories whose visual changes matter, and use CI logs and artifacts to identify slow or unstable setup steps.

Reliability depends on reproducing the build and capture environment and ensuring references are available to the job. Pin dependencies through the project’s lockfile, make server readiness explicit when using a server, and retain outputs for failed runs when the CI provider supports it. Loki itself does not define the provider’s scheduler reliability or artifact retention.

Loki is software used in your CI workflow. Any CI compute or artifact cost depends on the provider and configuration; the reviewed Loki sources do not state a price.

Or skip the browser setup

If you need a screenshot of a public page by URL rather than a Storybook regression run, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation for request options.

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

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Cookie banners are accepted and removed before capture; known consent platforms, newsletter popups, and chat widgets can also be removed, with each step configurable.
Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing; response headers report the page verdict and billing status.
An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents and MCP clients.
The free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 screenshots; every feature is on every plan.

FAQ

Can Loki schedule screenshots by itself?

The reviewed Loki documentation describes running in CI, not a Loki-native time scheduler. Configure recurrence in your CI provider.

Does this schedule screenshots of any live website?

The documented Loki workflow is for Storybook visual regression testing. For URL-based captures of public pages, ScreenshotNeo offers a separate screenshot API.

Should a scheduled run update reference images automatically?

No. Treat the run as a comparison, review the differences, and update references only after confirming the visual change is expected.

Where can I find the failed captures?

Look in Loki’s current and difference directories, then configure your CI provider to retain those files as artifacts when available.