Log Reference

Reference for reading PowerSync Service logs: what the structured fields mean, what common log lines indicate, and whether each one needs action.

This reference explains the log lines under Sync & API logs and Replicator logs, starting with the most common structured fields. To view them, open the PowerSync Dashboard, select your project and instance, and go to the Logs view. If you self-host, use your own log aggregator.

For error code lookups, see Error Codes Reference. For how to view, filter, and export logs, see Monitoring and Alerting.

Field Glossary

Most log lines carry structured fields alongside their human-readable message. Because message wording can change between Service versions, filter on these fields rather than the message text. The table below covers the fields on most lines, but a line can carry many more (especially with metadata expanded), and each source connector adds its own. Treat fields not listed here as additional context, and see the Detailed Event Reference for fields specific to individual events.

Field	Meaning
level	Log severity: info, warn, error, or fatal.
timestamp	ISO-8601 UTC time the line was emitted.
rid	Request ID. The same rid appears on both the start and complete line of a session, so you can correlate them. The prefix marks the endpoint type: s/ for the WebSocket sync stream, h/ for HTTP API requests.
user_id	The authenticated user ID extracted from the client’s JWT.
client_id	The client device ID, assigned per install by the SDK. One user can have many clients, so this differs from user_id.
user_agent	The SDK and platform the client reported, for example powersync-js/1.43.1 powersync-react-native react-native/0.77 ios/26.5.
app_metadata	Custom metadata the client attached via connect({ params }). See Custom Metadata in Sync Logs.
client_params	The parameter values the client passed to connect(). Large values may be truncated.
pod	The Kubernetes pod that emitted the line. Distinguishes pods in a multi-pod deployment.
duration_ms	Wall-clock duration of the request in milliseconds. On streaming access log lines this is the full session length.
stream_ms	How long a sync session stayed open, in milliseconds. Same value as the duration_ms on the session’s streaming access log line.
operations_synced	Total number of operations sent to the client during the session.
operation_counts	Per-type breakdown of operations: { "put": N, "remove": N, "move": N, "clear": N }.
data_synced_bytes	Uncompressed (plaintext) bytes synced to the client.
data_sent_bytes	Bytes actually sent over the wire. Smaller than data_synced_bytes when compression is enabled.
close_reason	Why a sync session ended. See Close Reasons.
status	HTTP response status code. 200 for streaming sync (it streams as 200 even if it later errors), 401 for auth failures, 429 for queue overflow.
error_code / errorData	The structured error on a failed line. errorData is { code, name, description, details?, severity, status }, where code is the PSYNC error code and details carries the underlying-driver message.
lsn	The source database position a checkpoint or flush corresponds to: a Postgres LSN, a MongoDB resume token, or an MSSQL LSN.
replication_lag / replication_lag_seconds	Seconds between when a change was committed on the source database and when the replicator flushed it to storage. Zero or one second is healthy. See Replication Lag.
checkpoint	The internal checkpoint op_id a sync session has reached.

Severity and Recovery

A line’s severity (level) does not necessarily tell you whether you need to act. Most error and warn lines describe transient events that the Service recovers from on its own:

• Per-session errors stay isolated to the affected client. Sync stream error and Streaming sync request failed tear down a single stream, and that client reconnects on its own. Service-wide failures such as a pod restart are the exception. They interrupt all connected clients until the Service recovers.
• The replicator retries source-database operations automatically, so transient connection drops, query timeouts, and keep-alive failures are caught, logged, and retried.
• Some error lines, such as Replication failed., trigger a pod restart that the supervisor handles automatically. Operator action is needed only when the cause persists across restarts.

To judge whether a line needs action, each table below includes a Recovery column:

Recovery	What it means
Auto	The Service handles it. No client or operator action required.
Client retries	A single client is affected. Its SDK reconnects.
Pod restart	The pod restarts automatically. Persistent occurrences usually point to a configuration or source-database problem.
Investigate	The line alone breaks nothing, but a burst of them is worth looking into.
Operator action	The Service cannot recover without intervention.

MongoDB is the storage backend for all PowerSync Cloud instances, which some lines reflect (for example Successfully activated storage: mongodb. or checksum errors like PSYNC_S2403). If you self-host on Postgres-backed storage, those lines look different.

Sync & API Logs

Produced by the PowerSync Service API pods. These cover client sync sessions (WebSocket and HTTP), HTTP API requests, checkpoint calculations, and write checkpoint endpoints.

Sync Session Lifecycle

These events trace a client’s sync session from start to finish. Searching for a rid returns both ends.

Event	Level	Recovery	When it fires
Sync stream started	info	n/a	A client opened a sync connection and authenticated. Both the HTTP streaming endpoint and the WebSocket endpoint emit this.
Sync stream complete	info	n/a	A sync session ended. The fields on this line summarize what the session did (operations_synced, data_synced_bytes, close_reason).
Sync stream error	error	Client retries	The WebSocket sync stream threw an exception and is being torn down. The SDK reconnects on its 5s retry. Other clients are unaffected.
Streaming sync request failed	error	Client retries	The HTTP streaming sync request threw an exception and is being torn down. Same impact as Sync stream error, but on the HTTP endpoint.

A short stream_ms paired with operations_synced: 0 usually means the connection was opened and torn down before any sync line was sent. This is normal when many clients reconnect at once, or when a client cancels quickly.

For the full field breakdown of each line, see Sync session field details below.

Close Reasons

The close_reason field on Sync stream complete takes one of these values:

Value	Recovery	Meaning
client closing stream	n/a	The client called disconnect() or its TCP connection closed cleanly. Normal for a session that ends because the user closed the app.
service closing stream	n/a	The server closed the stream for non-error reasons, for example because the Sync Config changed and existing streams need to reconnect.
stream error	Client retries	An exception was thrown during the stream. See the preceding Sync stream error or Streaming sync request failed for details.
process shutdown	n/a	The API pod is shutting down (deploy, scale-down, restart).
unknown	Investigate	The session ended without a recognized cause. Treat as a likely bug if it appears frequently.

Checkpoint Events

The PowerSync Service computes checkpoints to decide whether each connected client needs new data. In steady state you mostly see Updated checkpoint lines with empty updated/removed arrays, which are rechecks where nothing changed for that user.

Event	Level	Recovery	When it fires
New checkpoint: ...	info	n/a	The first checkpoint sent to a session, or after a parameter or sync-stream membership change forces a full checkpoint.
Updated checkpoint: ...	info	n/a	An incremental checkpoint (diff).

New checkpoint: 1152792849 | write: 1585 | buckets: 2 | param_results: 2 ["1#global[]","1#user_bucket[81097]"]

For the full payload breakdown, see Checkpoint payload anatomy below.

Common Errors in Sync & API Logs

Code	What it means	Recovery
PSYNC_S2001	Generic internal server error wrapper. The real cause is in the nested error.	Depends on cause
PSYNC_S2103	JWT has expired. The client should be refreshing credentials.	Client retries
PSYNC_S2305	Too many buckets for the user. Sync for this user is blocked until either the data or the Sync Config changes. See Troubleshooting: Too Many Buckets.	Operator action (per user)
PSYNC_S2401	Checksum mismatch. The client deletes the affected bucket and re-fetches. No data loss.	Auto
PSYNC_S2403	Query timed out while reading checksums (MongoDB storage). The Mongo aggregate that builds the checkpoint exceeded its timeout (50s).	Client retries

For the full code list, see Error Codes Reference.

Replicator Logs

Produced by the replication pod that pulls changes from your source database (Postgres, MongoDB, MySQL, or MSSQL) and writes them into the PowerSync storage layer.

Most replicator lines are prefixed with the Sync Config identifier in brackets, for example [powersync_69b93ff7358aa0646ff0dbca_1_e6dc]. The format is [powersync_<instance_id>_<group_id>_<hash>]. The group_id increments when the Sync Config changes, so a new version means a new group. Use this prefix to scope log queries to a particular Sync Config iteration.

Streaming Replication (Steady State)

Once initial replication is done, the replicator streams changes. The Flushed line is the most important steady-state line and the bulk of normal replicator logs.

[<sync_rule>] Flushed N + M + K updates, Xkb in Yms. Last op_id: Z. Replication lag: Ls

Component	Meaning
N + M + K updates	N = bucket data rows written. M = bucket parameter rows written. K = current_data records updated (the source-row mirror used for parameter recalculation).
Xkb	Uncompressed size of the bucket data written in this flush.
Yms	Wall-clock time the flush took. Sustained values above ~500ms indicate the storage layer is under load.
Last op_id: Z	The highest internal op_id assigned in this flush. Increases monotonically across all flushes for the iteration.
Replication lag: Ls	Seconds between when the oldest uncommitted change in this flush was made on the source and when it was flushed to storage. Zero or one second is healthy. Sustained values above 60s warrant investigation. See Replication Lag.

The same numbers appear as a structured flushed object on the line, easier to filter on than the message text:

"flushed": {
  "bucket_data_count": 14,
  "parameter_data_count": 0,
  "current_data_count": 14,
  "duration": 5,
  "size": 7498,
  "replication_lag_seconds": 0
}

If Replication lag is absent, the flush had no source-side change timestamps to derive it from. This happens only on snapshot flushes, never steady-state.

Replication Health

These lines report problems in the replication loop. Almost all are non-fatal, and the replicator handles them on its own.

Event	Source DBs	Level	Recovery	What it indicates
Failed to ping connection	Postgres	warn	Auto	A pooled connection failed its health check. Dropped and replaced.
KeepAlive failed, unable to post to WAL	Postgres	warn	Auto	The replicator could not write a keep-alive heartbeat to the source WAL. Usually transient (source briefly read-only, brief network blip). Sustained occurrences indicate credentials or permissions.
KeepAlive failed, unable to write an update to the <table>	MSSQL	warn	Auto	Same as above, for MSSQL.
Could not check RLS access for <schema>.<table>	Postgres	warn	Investigate	The replicator could not verify whether its user bypasses Row-Level Security. If RLS is in fact enforced, you will see missing data downstream.
Could not query max_slot_wal_keep_size	Postgres	warn	Investigate	The Postgres user lacks permission to read pg_settings. Cosmetic, but indicates a permission gap.
Query error, retrying..	MSSQL	warn	Auto	A CDC query failed and is being retried.
Replication error	All	warn	Auto	A non-fatal error in the replication loop. The replicator retries.
Replication failed.	All	error	Pod restart	Top-level error from the replication job loop. The pod is being restarted by the supervisor. Persistent occurrences usually carry a PSYNC code and indicate the underlying cause needs intervention.
Fatal replication error	All	error	Pod restart	Same as above.

Common Errors in Replicator Logs

Code	What it means	Recovery
PSYNC_S1003	Replication stream is locked by another process. Normal for up to 1 minute after a deploy or after a process was killed; the lock has a 60s TTL.	Auto (within 1 minute)
PSYNC_S1004	JSON nested object depth exceeds 20. Affects replication of that row.	Operator action (data fix)
PSYNC_S1146	Postgres replication slot was invalidated (source dropped it or exceeded max_slot_wal_keep_size). Replication restarts from snapshot.	Auto (re-snapshot)
PSYNC_S1344	MongoDB change stream invalidated. Replication restarts with a new change stream.	Auto
PSYNC_S1345	MongoDB change stream timed out reading from the source.	Auto (retry)

For the full code list and additional connector-specific codes, see Error Codes Reference.

Detailed Event Reference

The sections above cover the most common lines. The events below are lower-frequency or verbose, collapsed here to keep the page scannable but documented in full.

Sync & API Logs

Sync session field details

Fields on Sync stream started

Field	Meaning
user_id, client_id, rid, user_agent, app_metadata	See Field Glossary.
client_params	Parameter values the client passed to connect(). Subject to size limits, so very large values may be truncated.

Fields on Sync stream complete

Field	Meaning
user_id, client_id, rid, user_agent, app_metadata	See Field Glossary.
stream_ms	Duration the session was open, in milliseconds. Same value as duration_ms on the corresponding STREAM /sync/stream access line.
operations_synced	Total operations sent to this client in the session.
operation_counts	Per-type breakdown: { "put": N, "remove": N, "move": N, "clear": N }.
data_synced_bytes	Plaintext (uncompressed) bytes synced to the client.
data_sent_bytes	Bytes actually sent on the wire. With compression enabled, this is smaller than data_synced_bytes.
encoding	Wire encoding used for the session, for example permessage-deflate (WebSocket compression).
large_buckets	Buckets that contributed an unusually large number of operations in this session, as an object mapping <bucket descriptor> -> <operation count>. Useful for spotting outlier buckets that dominate a session’s payload.
close_reason	Why the session ended. See Close Reasons.

Fields on Sync stream error and Streaming sync request failed

Field	Meaning
user_id, client_id, rid, user_agent	See Field Glossary.
errorData	Structured error: { code, name, description, details?, severity, status }. The code is the PSYNC code, and details carries the underlying-driver message (for example, "Connection to <mongo host>:<port> interrupted due to server monitor timeout").
is_service_error	true when the error came from a recognized Service code path; false for unexpected exceptions.
stack	Stack trace from the throw site. Useful for cross-referencing against the Service source.

Checkpoint payload anatomy

Example payloads:

New checkpoint: 1152792849 | write: 1585 | buckets: 2 | param_results: 2 ["1#global[]","1#user_bucket[81097]"]

Updated checkpoint: 1152792918 | write: 376 | buckets: 2 | param_results: 0 | updated: ["1#user_bucket[72594]"] | removed: []

Component	Meaning
1152792849	The internal checkpoint op_id this session is at.
write: 1585	The latest write checkpoint applicable to this user, if any. null if there are no pending writes. See Write Checkpoints in the PowerSync protocol.
buckets: 2	The total number of buckets visible to this user given current parameters. The default cap is 1,000 (see PSYNC_S2305).
param_results: 2	The number of distinct parameter results evaluated for this user. Each parameter result corresponds to a row returned by a parameter query.
[<bucket descriptors>]	The list of bucket descriptors, truncated to 20. Format is <priority>#<stream_name>_<version>[<parameter_values>].
updated: [...] (Updated only)	Buckets whose data changed since the previous checkpoint.
removed: [...] (Updated only)	Buckets that left the user’s set since the previous checkpoint.

Structured fields on the same line include checkpoint (the op_id), buckets (count), parameter_query_results (count), and on Updated checkpoint only, updated and removed counts as integers. These are easier to filter on than parsing the message body.

HTTP endpoint and write checkpoint events

Event	Level	Recovery	When it fires
STREAM /sync/stream	info	n/a	RSocket access log line for a WebSocket sync subscription. Emitted on stream close, so the duration_ms is the full session length. Carries client_id, rid, duration_ms, user_id, user_agent.
GET /write-checkpoint2.json?client_id=<uuid>	info	n/a	A client requested a write checkpoint number to wait for. See Write Checkpoints in the PowerSync protocol. Carries method, path, route, status, rid, duration_ms.
Write checkpoint for <user>/<client>: <num> | <lsn>	info	n/a	Result of a write checkpoint computation. <lsn> is the source database LSN this checkpoint corresponds to (Postgres LSN, MongoDB resume token, MSSQL LSN).
Currently have N active WebSocket connection(s)	info	n/a	Periodic count of open WebSocket connections on this pod. Per-pod, not per-instance.
<METHOD> <path> with status: 429, queue_overflow: true	warn	Client retries	The request queue is full and the request is being rejected with HTTP 429. The client retries on its own.

Every HTTP access log line carries these structured fields. They are not visible in the rendered message but are filterable.

Field	Meaning
method	HTTP method, for example GET, POST, STREAM.
path	Full request path, including query string.
route	The matched route template (with placeholders), useful for grouping.
status	HTTP response status code. 200 for streaming sync (it streams as a 200 even if it later errors), 401 for auth failures, 429 for queue overflow.
duration_ms	Wall-clock duration in milliseconds. For streaming endpoints this is the full session length.
rid	Request ID. h/ prefix for HTTP, s/ for sync stream.

Concurrency and queueing

These appear when the API pod is near its configured concurrent-sync limit.

Event	Level	Recovery	When it fires
Sync concurrency limit reached, waiting for lock	info	Auto	A new sync session is queued behind currently-active sessions. It will start when a slot frees up.
Got sync lock. Slots available: N	info	n/a	The queued session acquired a slot.
Releasing sync lock	info	n/a	The session released its slot, either because it finished or because it errored.

Frequent Sync concurrency limit reached typically means traffic exceeds what the pod can handle, or the per-pod cap is set too low. See Production Readiness Guide.

Replication propagation (observed from the API pod)

Event	Level	Recovery	When it fires
Waiting for LSN checkpoint: <lsn>	info	n/a	The write checkpoint endpoint is waiting for the replicator to catch up to <lsn>.
Got write checkpoint: <lsn> : <checkpoint>	info	n/a	The wait completed; the checkpoint number is returned to the client.

A long delay between these two lines means the replicator is behind. If sustained, see Replication Lag.

Replicator Logs

Startup and lifecycle

Fired when a replication pod starts, stops, or restarts. Outside of a deploy, these usually mean the pod was killed and restarted by the supervisor.

Event	Level	Recovery	When it fires
Starting system	info	n/a	First line after the pod starts.
Starting Storage Engine... / Successfully started Storage Engine.	info	n/a	The bucket storage backend is being connected. The Successfully activated storage: <type> line in between names the backend (typically mongodb for Cloud).
Starting Replication Engine... / Successfully started Replication Engine.	info	n/a	The replication subsystem is initializing.
Starting Replicator: <id>	info	n/a	One per source database connection (for example postgresql-postgres).
Starting Router Engine... / Running on port 8080 / Successfully started Router Engine.	info	n/a	The replicator’s HTTP health and metrics endpoints are up. The replicator does not serve sync traffic.
Loaded sync config (or Loaded sync rules)	info	n/a	The current Sync Config was loaded from storage. Both wordings exist depending on Service version.
No sync streams or rules configured - configure via API	info	n/a	No Sync Config is deployed yet.
Locked replication stream for processing	info	n/a	This pod has acquired the replication lock for a Sync Config iteration. Only one pod can replicate a given iteration at a time.
Sync rules N has been locked for replication with lock ID <hex>	info	n/a	Companion line emitted after Locked replication stream for processing. The lock ID is the 8-byte hex identifier this pod is holding. Useful for confirming which pod owns the active lock.
[PSYNC_S1003] Sync rules N have been locked by another process for replication, expiring at <ts>.	info	Auto	Pod tried to acquire the lock but another pod (or a prior incarnation of this pod) still holds it. The lock has a 60s TTL, so this typically clears within a minute. Logged at info (not warn) precisely because it is expected behavior.
Successfully registered Replicator <id> with ReplicationEngine	info	n/a	Per-connector registration event during startup.
System started	info	n/a	All subsystems are up. The pod is actively replicating.

Sync Config changes

Event	Level	Recovery	When it fires
Failed to update sync config	error	Pod restart	Sync Config update validation failed. The pod exits and the supervisor restarts it.
Stopping replication job for sync rule iteration: N	info	n/a	An older Sync Config iteration is being stopped, usually because a new iteration replaced it.

Shutdown sequence

Triggered by SIGTERM (deploys, scale-down) or by a fatal error. A clean shutdown ends with Exiting. Lines you will see in order:

Stopping Replicator: <id>
Shutting down Replication Engine...
Terminating gracefully ...
[<sync_rule>] Stopping replication job for sync rule iteration: N
Shutting down Storage Engine...
Shutting down HTTP server...
HTTP server stopped
Closing N streams.
Running cleanup.
Shutting down Router Engine...
Successfully shut down Router Engine.
Successfully shut down Replication Engine.
<Connector> connection Managers shutdown completed.
Shutting down <Connector> connection Managers...
Exiting
Successfully shut down Storage Engine.

If you see Replication failed. or Fatal replication error before the shutdown lines, the pod is being restarted by the supervisor after a crash.

Initial Replication

The first time a Sync Config iteration is set up, every table covered by it is copied over. The exact wording differs by source database.

Event	Source DBs	Level	Recovery	When it fires
To replicate: <schema>.<table> <count>/<total>	Postgres, MongoDB	info	n/a	Logged once per table before the snapshot starts. The fraction is replicated rows over estimated total.
Replicating <schema>.<table> <count>/<total> - resumable	Postgres	info	n/a	Table snapshot is starting or resuming. resumable means the snapshot is chunked on the table’s single-column primary key, so it can pick up after an interruption.
Replicating <schema>.<table> <count>/<total> - not resumable	Postgres	info	n/a	The table has a composite primary key or no usable primary key, so an interrupted snapshot has to restart from the beginning.
Replicating <schema>.<table> <count>/<total> - resuming from <pk_col> > <value>	Postgres	info	n/a	An interrupted resumable snapshot is picking up from a stored cursor.
Replicating <schema>.<table> <count>/<total>	Postgres, MongoDB	info	n/a	Progress update during a snapshot, logged per chunk flush.
Snapshotting <schema>.<table> <count>/<total>	MSSQL	info	n/a	MSSQL CDC equivalent of Replicating.
Skipping <table> - snapshot already done (or Skipping table [<table>] - snapshot already done.)	All connectors	info	n/a	Table has already been fully snapshotted for the current iteration. Logged on startup when resuming.
Initial replication already done	All connectors	info	n/a	All tables in the iteration are already snapshotted. The replicator goes straight to streaming.

Snapshot completion and replication slot management

Event	Source DBs	Level	Recovery	When it fires
Created replication slot <slot_name>	Postgres	info	n/a	A new logical replication slot was created. Happens on first replication or after the previous slot was dropped (Sync Config changes, slot health check failure, pg_drop_replication_slot, pg_upgrade). See Postgres Maintenance.
Cleaning up Postgres replication slot: <slot_name>...	Postgres	info	n/a	A slot is being dropped, usually after Sync Config changes. The next replication run creates a fresh slot.
WAL budget: no limit configured (max_slot_wal_keep_size is unlimited).	Postgres	info	n/a	Source Postgres has no slot retention limit. Normal.
WAL budget: ... budget-low	Postgres	warn	Investigate	max_slot_wal_keep_size is set and the slot is approaching it. If the slot is invalidated, replication has to restart from snapshot. See PSYNC_S1146.
Marking snapshot at <lsn>	MongoDB, MSSQL	info	n/a	The snapshot transaction captured all tables at <lsn>. Streaming will resume from this point.
Resuming snapshot at <lsn>	MongoDB, MSSQL	info	n/a	A previously interrupted snapshot is resuming from a stored LSN.
Flushed snapshot at <op_id>	MongoDB	info	n/a	The MongoDB snapshotter finished writing a collection up to the resume token <op_id>.

Streaming replication variants

Beyond the Flushed line, the streaming phase emits these connector-specific lines.

Event	Source DBs	Level	Recovery	When it fires
[<sync_rule>] Replicating op N <lsn>	Postgres	info	n/a	Periodic progress log during initial sync streaming, every 100 operations.
[<sync_rule>] Processed batch of N changes / X bytes in Yms	MongoDB	info	n/a	A batch of MongoDB change-stream events was consumed from the source. Carries structured fields count, bytes, duration, useful for filtering on slow batches.
Resume streaming at <token> / <lsn> | Token age: Ns	MongoDB	info	Investigate if Token age is large	The change stream resumed from a stored token. Token age approaching MongoDB’s oplog retention window means the slot is at risk.
New collection: <schema>.<name>	MongoDB	info	n/a	A new matching collection was discovered after replication started. It will be snapshotted before streaming resumes.
Enabled postImages on <db>.<collection>	MongoDB	info	n/a	The replicator enabled changeStreamPreAndPostImages on a collection that needs it for replica identity. Done once per collection.

The Flushed line’s structured flushed object maps to the message components as follows:

Sub-field	Maps to message component
bucket_data_count	N
parameter_data_count	M
current_data_count	K
duration	Yms
size	Bytes (the Xkb value is size / 1024, rounded).
replication_lag_seconds	Ls

Schema changes

Event	Source DBs	Level	Recovery	When it fires
Processing schema change <type> for table [<schema>.<table>]	MySQL	info	n/a	A DDL event from the source binlog is being applied to the replicator’s schema view.
Successfully processed N schema change(s).	MySQL	info	n/a	All DDL events from one binlog chunk were applied.
Table <schema>.<table> has been dropped. Handling schema change...	MSSQL	info	n/a	The MSSQL CDC poller noticed a tracked table was dropped or its capture instance was removed. Handled by halting replication for that table or re-snapshotting, depending on config.
Unable to retrieve schema changes for capture instance: [<name>].	MSSQL	warn	Auto	Schema delta query failed. Usually a transient permissions or connection issue.

CDC polling (MSSQL only)

The MSSQL connector polls CDC capture tables rather than streaming a logical replication slot.

Event	Level	Recovery	When it fires
CDC polling started with interval of Nms...	info	n/a	Replication is starting. N is the polling interval in ms (default 1000).
Polling a maximum of N transactions per polling cycle.	info	n/a	The per-cycle batch limit.
Polling bounds are <startLSN> -> <endLSN> spanning N transaction(s).	info	n/a	One polling cycle’s range.
CDC polling stopped...	info	n/a	The polling loop is shutting down.