Vercel

The Vercel integration creates JSON log drains for selected projects and forwards their log entries into GraphJSON collections.

Requirements#

Vercel’s current Log Drains capability is available on eligible Vercel plans. Check the Vercel Log Drains reference for current provider availability, formats, fields, and billing.

Connect a project#

1. Create or choose a collection, such as vercel_production_logs.
2. Open Integrations.
3. Choose Vercel and connect the intended personal account or team.
4. Map a Vercel project to a GraphJSON collection.
5. Create the drain.
6. Generate a runtime or build log in that project.

You can map different projects to different collections to keep ownership, retention, and alerting clear.

Inspect the payload#

Open Samples and identify the fields your Vercel project sends. Depending on source and provider version, useful fields can include:

projectId
deploymentId
source
level
message
path
statusCode
environment
requestId
executionRegion

Nested values are flattened into dot-separated keys.

Start with focused metrics#

Errors over time#

• graph: Single Line
• aggregation: Count
• filter: level = error
• granularity: Hour

Create a separate alert for fatal if the source sends that level.

Errors by path#

• graph: Bar Chart
• aggregation: Count
• split: path
• filter: level = error

High-cardinality paths with raw identifiers can fragment this view. Prefer normalized route fields when available.

SQL query#

SELECT
  JSONExtractString(json, 'level') AS level,
  JSONExtractString(json, 'source') AS source,
  count() AS logs
FROM vercel_production_logs
WHERE toDateTime(timestamp) >= subtractHours(now(), 24)
GROUP BY level, source
ORDER BY logs DESC

Set retention deliberately#

Operational logs can be high volume and may contain request details. Use a shorter collection retention period unless you have a defined need for long-term history.

Review application logging so messages do not contain access tokens, authorization headers, session cookies, or customer secrets before enabling a drain.

Understand source volume#

Vercel can batch multiple JSON log objects in one delivery. A single application request may also produce more than one log entry, especially around rendering and regeneration behavior.

Count logs as log records, not necessarily requests or users. Use a stable request identifier when the payload provides one and the metric requires request-level deduplication.

To compare errors, latency, and product outcomes across deployments, add an immutable release identifier and explicit deployment events using Release-impact analytics.

Normalize high-cardinality fields#

Raw request paths, messages, deployment IDs, and request IDs can create a long tail.

Prefer:

• normalized route template over raw URL
• status family over every status when a summary is enough
• deployment ID for release investigation
• request ID only for drill-down and deduplication

Do not split a chart by raw request ID, complete URL, or free-form error message.

If a path contains customer or object identifiers, normalize it in application logging before Vercel forwards it.

Monitor the drain#

Keep a Vercel-side owner who can inspect:

• connected team and project
• drain status
• eligible plan
• runtime and build-log behavior
• project deletion or transfer

In GraphJSON, monitor:

• last log occurrence time
• records by source, level, environment, and project
• unknown levels
• missing deployment IDs
• sudden record-volume changes
• largest payloads

When logs stop:

1. confirm the project still produces the expected log
2. check that the drain exists on the intended Vercel team
3. check project-to-collection mapping
4. generate one safe request to a known route
5. compare Vercel time with GraphJSON Samples
6. reconnect only after recording the missing interval

Vercel log drains generally describe delivery from the active connection forward. Do not assume reconnecting automatically backfills an earlier gap.

Change projects or teams#

A project transfer can change who owns the drain and which authorization is valid.

Treat it as a cutover:

1. record the last deployment and request ID on the old connection
2. connect the intended team
3. create the new project mapping
4. generate a canary request
5. verify environment, source, and deployment fields
6. watch for duplicate drains
7. remove the old mapping after validation

Do not leave two active drains writing the same project into one metric unless deduplication is deliberate.

Disconnect#

Delete the mapping from the GraphJSON Vercel integration page, then confirm the drain no longer appears in Vercel. Removing a drain stops future delivery but does not delete events already stored in GraphJSON.

Use Operate managed integrations for shared monitoring, incident, reconnection, and retirement procedures.