How to Fix Argos CI Screenshot Upload Errors in GitHub Actions in India

To fix an Argos CI screenshot upload error in GitHub Actions, identify the exact failing workflow step, then check in order that screenshots were generated, the Argos uploader is configured to run in CI, the workflow has a valid authentication route, and the runner can reach the required services. Use the logs to distinguish these causes before changing the workflow. The reviewed documentation does not establish an India-specific Argos endpoint or India-only fix.

This guide focuses on the documented Argos Playwright integration and direct Node.js uploads. It also covers GitHub Actions authentication choices, self-hosted runner networking, baseline confusion, and a screenshot API alternative when your task is to capture a page rather than upload Playwright test artifacts.

1. Locate the failing step before changing anything

Open the failed Actions run and identify the job and exact step that failed: test execution, screenshot generation, reporter initialization, authentication, or upload.
Read the complete error and surrounding log lines. Note whether the upload was attempted and whether it reports zero files, an authorization rejection, a timeout, or a connection/TLS error.
If normal logs are not detailed enough, enable GitHub Actions debug logging and the relevant tool-level verbose output. GitHub recommends additional debug logging when workflow logs do not explain a failure. See GitHub’s workflow troubleshooting guide.
Record the run URL and timestamp, event type (push, internal pull request, or fork pull request), runner type, failing step, exact error, expected upload root and file pattern, and authentication method. Redact tokens, cookies, and other secrets before sharing logs.

Do not infer that an error is India-specific from the runner’s location. The reviewed Argos and GitHub guidance describes general setup and network diagnosis; it does not document an India-specific upload host or regional workaround.

2. Confirm the screenshots exist and match the upload selection

A successful test run does not guarantee that the uploader found image files. Check the artifact directory at the point the upload runs and compare it with the configured root and glob.

In the Argos Playwright quickstart, argosScreenshot writes screenshots to ./screenshots by default. The documented direct Node.js upload example uses root: "./screenshots" and files: ["**/*.png"]. If your project writes elsewhere, use its actual path and file extensions rather than copying these defaults blindly.

// Example: list the files in the documented default directory before upload.
import { readdir } from "node:fs/promises";

const files = await readdir("./screenshots");
console.log("Screenshot files:", files);
if (files.length === 0) {
  throw new Error("No files found in ./screenshots");
}

This small check only inspects the directory’s top level. If screenshots are nested, inspect recursively or adjust it to match the upload glob. Also confirm that the files are PNG if the pattern is **/*.png; a directory containing only JPEGs will not match.

Check the upload root and pattern

Verify the process working directory. A relative path such as ./screenshots is resolved from the process’s current directory.
Check spelling, capitalization, and whether the directory is created in the same job and workspace as the uploader.
Match the glob to generated extensions and nested paths, such as PNG versus JPEG and top-level versus nested files.
If tests run in parallel or write to separate worker directories, make sure those outputs are collected in the upload root before upload begins.
Make sure screenshot creation completed before the upload step starts; do not rely on a background process that may still be writing files.

3. Verify the Argos Playwright reporter runs in CI

For the documented Playwright integration, configure the Argos reporter and make sure the upload behavior is enabled in the Actions environment. The quickstart shows uploadToArgos: !!process.env.CI; if the workflow does not set CI as expected, the reporter may not attempt an upload.

// playwright.config.ts — illustrative setup based on the Argos Playwright quickstart.
import { defineConfig } from "@playwright/test";
import { argosReporter } from "@argos-ci/playwright";

export default defineConfig({
  reporter: [
    ["list"],
    [argosReporter({
      uploadToArgos: !!process.env.CI,
    })],
  ],
});

Use the package names and exact configuration supported by the version installed in your project; consult the Argos Playwright quickstart for the current setup. Confirm the workflow actually reaches the screenshot call and reporter shutdown/upload path. If there is no reporter output and no upload attempt, investigate test flow, package/config loading, and CI detection before changing firewall rules.

4. Choose and verify an authentication route

The documented project-token route passes ARGOS_TOKEN to the test job. The Argos Playwright quickstart identifies the token in Argos Settings → General → Token. Argos also documents GitHub Actions OIDC and tokenless authentication in its May 11, 2026 changelog. The correct route depends on the workflow event and which credentials that event can access.

Route	Check	When to consider it
Project token	Confirm the token belongs to the intended Argos project and is exposed to this job as `ARGOS_TOKEN`. Never print it in logs.	A straightforward configured secret is available to the workflow event.
GitHub Actions OIDC	Argos documents a GitHub-signed identity flow. The workflow needs `id-token: write`, and project-side authentication must be configured. Follow the linked current Argos instructions.	You want the documented OIDC path and can configure its workflow permissions and project setup.
Tokenless authentication	Check the Argos changelog’s linked setup and verify that the repository/workflow is linked and accepted. The changelog describes a fallback for cases where OIDC is unavailable, including forked pull requests.	OIDC or a repository secret is unavailable for the event, subject to Argos’s current verification requirements.

Forked pull requests commonly require special care because repository secrets may not be available to them. Do not assume a missing ARGOS_TOKEN is an Argos outage. Check the event type and use the current documented OIDC or tokenless setup if appropriate. The exact configuration can change, so verify it in the Argos setup documentation and the Argos changelog.

5. Separate upload failures from baseline and comparison issues

Argos needs a build on the default branch as a comparison baseline. Before that baseline exists, pull request builds may appear as orphan. An orphan build can therefore indicate missing comparison history rather than failed screenshot transfer. Check whether the build uploaded and then inspect the default-branch baseline separately.

6. Diagnose timeout, connection, and TLS errors from the runner

If files exist and authentication appears configured but the upload times out or fails to connect, inspect the network path from the machine running the job. GitHub’s troubleshooting guidance names DNS, firewalls, proxies, certificates, IP allow/deny lists, subnet configuration, and third-party service status as possible areas to check.

GitHub-hosted runners

Check the exact run’s logs and current status of the relevant third-party service.
Compare a failing event with a successful event, if available, to identify differences in job environment or authentication availability.
Do not copy a generic GitHub Actions IP list into an allowlist as an assumed Argos fix. The reviewed sources do not provide an Argos-specific destination allowlist.

Self-hosted runners

Run the GitHub runner configuration connectivity check using its documented --check option. This checks connectivity to required GitHub services; it does not prove connectivity to Argos.
Confirm outbound HTTPS on port 443 is allowed for GitHub runner communication, then separately review the organization’s egress rules for the third-party upload path.
Check the runner’s DNS resolution, proxy configuration, trusted certificate chain, firewall rules, and any network inspection device for the failing connection.
Repeat diagnostics from the runner host or container that runs the workflow. A developer laptop’s successful connection does not verify the runner’s network path.

GitHub documents its runner connectivity check and outbound requirements in the self-hosted runner troubleshooting guide and self-hosted runner reference. Those are GitHub connectivity facts, not an Argos-specific network allowlist or a claim about Indian networks.

7. Use a direct Node.js upload only when your integration calls for it

If your project intentionally uploads files directly with the Argos core package rather than relying on the Playwright reporter, make the selected root and pattern explicit. This example follows the documented selection shape; check the current Argos package documentation for the installed version’s exact invocation and authentication configuration.

// Node.js example: configure the documented root and PNG glob.
import { upload } from "@argos-ci/core";

await upload({
  root: "./screenshots",
  files: ["**/*.png"],
});

Use one upload route intentionally. If both the reporter and a direct upload run, you may create duplicate or confusing build behavior. Confirm which integration owns the upload and inspect its logs.

8. A focused decision tree

What the run shows	Likely area to investigate	Next check
No upload attempt or reporter output	Reporter/configuration, CI detection, job flow	Confirm package setup, `CI`, screenshot call, and that tests reach reporter completion.
Upload reports no files or an empty build	Screenshot generation or file selection	Inspect files at upload time; compare root, working directory, glob, and extension.
Authentication or permission rejection	Token missing/invalid or event cannot access credentials	Check project token exposure, event type, or configured OIDC/tokenless route.
Timeout, connection, or TLS error	Runner network path or service availability	Check DNS, proxy, firewall, certificates, egress policy, and third-party service status from the runner.
Build is uploaded but marked orphan	Default-branch baseline is not established	Run a baseline build on the default branch and inspect comparison state.

9. India-specific checks and limits

The reviewed Argos setup and authentication sources do not identify an India-specific upload URL, regional endpoint, or India-only workflow requirement. If the runner is self-hosted in India, test connectivity from that runner and check the company’s proxy and egress policy. If it is GitHub-hosted, use the specific run logs and current service status rather than attributing the problem to India without evidence.

If the issue remains unresolved, send Argos support the run URL, timestamp, exact error text, runner type and region, event type, upload root/glob, authentication method, and redacted network diagnostics. Do not include the token. Ask whether they can confirm any current regional endpoint or connectivity guidance; the sources reviewed here do not settle that question.

10. Keep the workflow reliable and the diagnosis inexpensive

Fail with useful context: preserve the original uploader error and identify the failing step. Avoid logging secret values while increasing diagnostic detail.
Validate artifacts before upload: checking that expected files exist catches path and timing mistakes before troubleshooting the network.
Keep authentication event-aware: decide explicitly how pushes, internal pull requests, and fork pull requests authenticate; do not expose secrets to untrusted code as a workaround.
Keep baseline setup distinct: establish a default-branch build so comparison status is not confused with transfer status.
Avoid unsupported quota assumptions: GitHub documents workflow and dependent-service limits, but those do not establish an Argos screenshot upload quota. Attribute a limit only when the service and error support it.

These checks add little operational overhead and can prevent wasted reruns. Re-run only after the log evidence points to a change: fixing a glob will not repair a firewall, and changing authentication will not create missing image files.

11. Or skip the browser setup

Argos is for visual test screenshots and comparison workflows. If your actual task is to capture a website as an image or PDF, ScreenshotNeo is a website screenshot API and MCP server for developers. It can return PNG, JPEG, WebP, or PDF from one GET request. Its parameters also work with names used by other screenshot APIs, which can make switching easier. See the ScreenshotNeo API documentation.

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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot; each cleanup step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are never billed, and response headers report the page verdict and billing status. Its MCP server gives AI agents screenshot, page-info, and PDF-capture tools. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

FAQ

Does this failure mean Argos is blocked in India?

No such conclusion follows from the reviewed documentation. Test the actual runner’s connection and use its error logs; no India-specific Argos endpoint or fix is established here.

Should I increase a GitHub Actions limit?

Only if the error identifies a GitHub limit. GitHub’s documented workflow and dependent-service limits do not establish an Argos upload quota.

What should I send support?

Share the run URL, timestamp, event type, runner type and region, exact error, expected file selection, authentication route, and redacted network details. Never share the secret token.

Is an orphan build proof that screenshots were not uploaded?

No. Argos documents that pull request builds can appear orphan before a default-branch baseline exists. Check transfer and baseline status separately.