Verification sources

A merged pull request doesn't tell you whether its deployment served production traffic or whether errors increased afterward. Connect a verification source when an acceptance criterion needs data from a deployment platform, telemetry service or HTTP endpoint.

Connect a source

An organization connects a source once in Settings > Integrations > Verification sources, then uses that connection across criteria. Several connections per provider are allowed, for example separate staging and production connections.

1. Select Add for the provider and give the connection a name that identifies its target.
2. Enter the provider settings and credentials described below. Managing connections requires org:manage.
3. Set Ingestion lag (minutes) if the provider default doesn't match your data's arrival time. Save and inspect the health result.

Choose the connection and check when proposing a criterion. A person must authorize the criterion before it counts. A successful connection health check establishes access to its health endpoint; it doesn't prove access to every check or confirm that you chose the intended project.

Address rules

ArchDocs connects only to public HTTPS addresses. Private networks, loopback and link-local addresses are refused, including when a hostname resolves to a private address. URLs cannot contain a username or password. Redirects are refused, even to another public HTTPS address. Use the final endpoint URL.

Responses are capped at 1 MB after decompression. A blocked address, redirect or oversized response leaves the source unavailable rather than supplying a passing value. Self-hosted services must have a public HTTPS endpoint to be used here.

Timing and ingestion lag

A window check measures over a duration. An until check looks for its condition before a deadline. The tables list the modes each check accepts. Every check takes a numeric comparison: at least, at most or equal to a value. Success checks use 1 for success and 0 for failure, with unavailable or insufficient data reported as inconclusive.

A start event sets the beginning of a run, for example a release deployment. You can also start when the criterion is authorized, at a date or after another criterion passes, and add a delay. Providers with no start events can still use these starts or an event from another connection.

Ingestion lag allows data to arrive before the final decision. The final read is scheduled after the window or deadline ends plus that lag. An until check can pass earlier; a window check with an at-most comparison can fail earlier. Leave the field blank to use the provider default, or set a connection override between 5 and 240 minutes.

Client-written data

The client-written label means the check reads data your application or workflows can write. Reading that data through a provider API does not make it independent evidence of runtime behavior. The tables identify these checks. PostHog event checks and Sentry telemetry checks carry the label; GitHub Deployments checks carry it because your team's workflows produce the records.

A check without this label still has the limits of its source. An HTTP response or a metric alone doesn't prove deployment correctness.

PostHog

Connection settings

Create a personal API key in your PostHog account with query:read, activity_log:read and feature_flag:read. Paste it into Personal API key. It must start with phx_. The form refuses project tokens starting with phc_, which send events, and keys without the phx_ prefix.

Enter the numeric project ID and the HTTPS API host for your region or self-hosted instance. The default is https://us.posthog.com; EU Cloud uses https://eu.posthog.com. Use the private API host, as described in PostHog's API overview, rather than an event ingestion host. The host cannot include URL credentials, a query or a fragment.

Checks and starts

An event selector names an event and optionally filters its properties by equality, inequality, case-insensitive containment or numeric greater-than/less-than. It accepts up to 10 filters. Count and ratio checks count events by default, or unique users when selected. Optional baseline comparisons return percentage change against the preceding window of equal duration.

Feature flag state reads the largest rollout percentage among groups without property restrictions. An inactive or missing flag, or a flag with only restricted groups, reads as zero. It doesn't evaluate whether a particular person receives a flag. A zero denominator makes an event ratio inconclusive; an event property with no samples is also inconclusive. Flag-change lookup reads at most five activity pages, so older changes may not be found.

Example criterion: after the checkout-v2 flag turns on, at least 100 checkout_completed events arrive during the following day. Use Event count, a window of one day and the flag-change start. These are example thresholds, not measured results. Allow for the default 60-minute ingestion lag.

Vercel

Connection settings

Enter a project ID or name and, for a team project, its team ID. Create a Vercel access token with access to that project and paste it into Access token. A token can be scoped to one project but cannot be made read-only. When the ArchDocs Vercel integration is configured, Install Vercel integration offers the installation flow instead of a pasted token.

The form refuses an empty access token for a direct connection. Vercel has no public ingestion key to use in its place. ArchDocs reads projects and deployments with the token through the Vercel REST API.

Checks and starts

The serving check requires Git commit metadata. CLI or upload deployments without a Git commit cannot establish that a commit was deployed and can read as inconclusive. Vercel's promoted state shows that a deployment has seen production traffic; it does not prove it is still the current production deployment. Promotion time can fall back to ready time when the API doesn't supply a numeric alias assignment time.

There is no rollback check. The API's last rollback target and rollback eligibility fields cannot count rollbacks over a window. Deployment history traversal is bounded; if it cannot complete, ArchDocs reports an unavailable result instead of a partial error count.

Example criterion: the Vercel production deployment for the merged commit has served production traffic within 30 minutes of merge. Use Deployment serving production, the merged commit SHA and an until deadline of 30 minutes, comparing the result to 1. This example uses the provider's promotion record, with the current-serving limitation above.

GitHub Deployments source

Connection settings

Use the organization's ArchDocs GitHub App installation. Give the App access to the repository and grant Deployments: read and Actions: read. No pasted secret is needed or accepted, including personal tokens and public or ingestion keys.

Enter the repository as owner/name, without a URL or .git suffix. Name the production environment exactly as your workflows use it; it defaults to production. A deployment check or start can override that environment. Repository health access alone doesn't prove the App has Deployments or Actions access.

Checks and starts

Workflow start conclusions can be success, failure, cancelled, timed out, action required, neutral, skipped, stale or startup failure. A missing deployment or an unfinished workflow is inconclusive. The check also leaves neutral or skipped workflow conclusions inconclusive. A later rerun or deployment can change the newest record used by a check. Repeated success statuses do not restart a deployment start.

These records are written by your team's own workflows. A recorded deployment success is not an independent probe of production traffic. Reads stop after 10 pages per endpoint and refuse partial history. Workflow completion starts use updated_at, which is a last-update timestamp rather than a dedicated completion timestamp.

Example criterion: GitHub records a successful deployment of the merged commit to production within 30 minutes of merge. Use Deployment succeeded with an until deadline of 30 minutes and compare to 1. Treat the result as a workflow-written deployment record.

Sentry

Connection settings

Create a Sentry internal integration token with org:read, project:read and event:read, then paste it into Auth token. Empty tokens and DSN URLs containing a public key are refused. A DSN sends events and is not a read credential.

Enter the organization slug and optionally a project slug or numeric ID to limit every query. Use the HTTPS host for your Sentry region or self-hosted service; the default is https://sentry.io. URL credentials, queries and fragments are refused.

Checks and starts

Error-count baselines use the preceding window of equal duration. Searches and release versions can use the linked revision's SHA, for example a release search tied to the merged commit.

Sentry rounds crash-free windows to at least an hour, so a sub-hour window cannot promise exact bounds. No sessions or a null rate is inconclusive. Only the latest deploy per release, project and environment is visible, so earlier repeated deployments of the same release may be unavailable. Deploy timestamps come from your deployment instrumentation and don't independently prove traffic movement.

The organization health endpoint may deny an internal integration token because Sentry's authentication guidance differs from its endpoint scope guidance. ArchDocs reports that denial as not authorized. Paginated reads refuse incomplete history rather than returning partial counts.

Example criterion: the production release has a crash-free session rate of at least 99.5% during the day after Sentry records its deployment. Use Crash-free rate with that release and environment, a one-day window and Release deployed as the start. The percentage and duration are example thresholds.

HTTP check

Connect an HTTP endpoint

Enter a public HTTPS base URL without URL credentials, a query or a fragment. For anonymous access, leave both header fields blank. For authenticated reads, supply Header name (optional) and Header value (optional), for example Authorization and a bearer value. Choose a credential that permits reads of the endpoint; its scopes depend on your service.

The form refuses a header name without a value or a value without a name. Reserved headers are Host, Cookie, Content-Length, Transfer-Encoding and Connection, regardless of case. Invalid header names and values containing a carriage return, newline or null character are refused.

Checks and starts

There are no HTTP start events. Paths stay on the configured origin and cannot start with // or contain a backslash. Both checks make a GET request when read; a window does not create a continuous uptime history.

Status codes 401 and 403 read as not authorized, and 429 as rate limited, rather than as status values to compare. Redirects remain unavailable. JSON values must be numbers, numeric strings or booleans (true becomes 1, false becomes 0). Missing or nonnumeric values are inconclusive; invalid JSON is a provider error. An empty JSON Pointer selects the whole document.

Example criterion: /health returns status 200 within 10 minutes after authorization. Use Status code with path /health, an until deadline of 10 minutes and an equality comparison to 200. This example checks observed responses, not uninterrupted availability.

Prometheus

Connection settings

Enter the public HTTPS API root, without /api/v1, URL credentials, a query or a fragment. ArchDocs appends /api/v1/query for reads. Supply exactly one credential form: Bearer token, or Username (Grafana Cloud instance ID) plus Password (Grafana Cloud metrics:read token).

For Grafana Cloud, the username is your metrics instance ID and the password is an access policy token with metrics:read. For another Prometheus service, use its read credential. The form refuses mixed bearer and username/password credentials, incomplete pairs and an instance ID alone. It also rejects invalid bearer token syntax and usernames containing a colon or a line break.

Checks and starts

There are no Prometheus start events. The query runs as an instant query at the end of the range. ArchDocs substitutes $__range with the range duration in seconds; put that variable in a range selector when you need an aggregate over the window.

A query must return exactly one number, either a scalar or a single instant-vector sample. An empty vector, several series, a matrix or a nonnumeric value is inconclusive. Aggregate across labels in the query rather than relying on ArchDocs to choose a series. Private-only Prometheus endpoints cannot be connected.

Example criterion: during the hour after a deployment, the total increase in http_requests_total is at least 100. Use sum(increase(http_requests_total[$__range])), a one-hour window and a deployment start from another connection. The count is an example threshold.

Datadog

Connection settings

Create an API key and an application key, preferably owned by a service account. Paste them into API key and Application key. Grant the application key the permissions for your reads: monitors_read (also used for health), timeseries_query, logs_read_data, events_read, dora_metrics_read and deployment_gates_read as applicable. Missing keys and client tokens starting with pub are refused.

Choose your site from datadoghq.com (default), us3.datadoghq.com, us5.datadoghq.com, datadoghq.eu, ap1.datadoghq.com, ap2.datadoghq.com, uk1.datadoghq.com, ddog-gov.com or us2.ddog-gov.com. ArchDocs uses that site's API host.

Checks and starts

Metric baselines compare with the preceding window of equal duration. Metric queries must return a single ungrouped number. Incomplete or warned log results are inconclusive. Scope queries to the intended service and release; a general monitor doesn't identify which revision produced a result.

Monitor stayed OK needs a known state at the start and no alert or warning during the window. Passing also requires a single-alert monitor currently OK. Missing history and multiple-alert monitors cannot establish a pass. A recovered alert still fails the window.

Deployment Gate reads use a preview API, checked on 2026-11-03. All matching evaluations must pass; any failure fails, including a recorded dry-run failure. Missing, in-progress or incomplete results are inconclusive. Gate windows longer than 30 days are inconclusive, and completed evaluations can take time to appear. DORA starts search at most 100 deployment records. The default 15-minute lag may need increasing for delayed cloud metrics.

Example criterion: the API service's monitor stays OK for the hour after Datadog records the merged commit's production deployment. Use Monitor stayed OK, a one-hour window and a Deployment start scoped to service, environment and commit SHA, comparing to 1. Choose a single-alert monitor with available state history.