Monitoring & Jobs

Synclet provides built-in tools for monitoring your data syncs — a real-time dashboard, detailed job history, per-connector logs, and Prometheus-compatible metrics for external observability.

Dashboard

The dashboard is the landing page after you log in. It provides a high-level view of your workspace’s sync health.

The 24h / 7d / 30d selector in the top right sets the time range of the stat cards and charts; 24h is the default.

Stat Cards

Card	What it counts
Total Syncs	Syncs that ran in the selected range.
Success Rate	Share of those syncs that succeeded.
Records Synced	Records read from sources in the range.
Active Connections	Connections whose status is active, whatever the range.
Failed Syncs	Syncs that failed in the range.

Every card but Active Connections carries its range in the label, for example Total Syncs (24h), and a trend line that compares it with the range before (the previous 24 hours, 7 days or 30 days): a percentage change, and for Success Rate the change in percentage points. Green means better and red worse, so for Failed Syncs a rise is red.

Charts

Chart	What it shows
Sync Timeline	Succeeded and failed syncs per hour (24h) or per day (7d, 30d).
Throughput	Records read per hour or per day.
Duration Trends	Average sync duration per hour or per day.
Failure Breakdown	The range’s failed jobs by cause: connector, timeout, oom, infrastructure or unknown, read from the error message.

Top Connections lists the five connections with the most records synced in the range, with their records, bytes, last sync and a trend sparkline.

Connection Health

The Connection Health grid has one tile per connection, linked to the connection’s page, with one of these labels:

Health	Meaning
Healthy	The last sync did not fail and the next one is not overdue, or the connection has not synced yet. A connection without a schedule is never overdue.
Warning	More than twice the schedule’s interval has passed since the last sync, or the schedule cannot be parsed.
Failing	The last sync failed, or more than three times the schedule’s interval has passed since the last sync.
Disabled	The connection is not active (inactive or paused), so no syncs are scheduled.

The Topology page draws every source, connection and destination as one graph, coloured by health, with filters for failing and enabled connections only.

Job History

Every sync run creates a job. You can browse all jobs from the Jobs page in the sidebar.

Job States

State	Description
Scheduled	The job is enqueued and waiting for a worker.
Starting	The job is initializing (pulling connector image, preparing workspace).
Running	The job is actively syncing data.
Completed	The job completed successfully.
Failed	The job failed after exhausting all retry attempts.
Cancelled	The job was manually cancelled by a user.

Filtering

You can filter the job list by:

• Connection — Show jobs for a specific connection.
• Status — Show only failed, succeeded, or running jobs.
• Date range — Narrow down to a specific time period.

Click any job to view its details.

Job Detail

The job detail page shows everything about a specific sync run.

Attempt Breakdown

Each job may have multiple attempts if retries are configured. For each attempt, you can see:

• Start time and end time.
• Duration.
• Status — whether the attempt succeeded or failed.
• Error message — if the attempt failed, the connector’s error output.

Sync Stats

For each attempt, the job detail shows aggregate sync statistics:

Metric	Description
Records read	Number of records read from the source.
Bytes synced	Data volume transferred.
Duration	Time spent on this attempt.

Errors

If a job failed, the error section shows the connector’s error output with timestamps. Common errors include authentication failures, schema mismatches, network timeouts, and rate limit violations.

Logs

Synclet captures logs from each connector during a sync. Logs are available per attempt in the job detail view.

Log Levels

Level	Description
INFO	Normal operational messages — records processed, state checkpoints.
WARN	Non-fatal issues — skipped records, deprecated features, approaching limits.
ERROR	Failures that caused the sync to stop — authentication errors, connection drops.

Logs can be filtered by level to focus on warnings and errors during troubleshooting.

Log storage and archiving

While a job runs, its log lines are stored in PostgreSQL and the UI tails them from there. Each attempt keeps at most PIPELINE_LOG_MAX_LINES_PER_ATTEMPT lines (100,000 by default, 0 disables the cap); later lines are dropped and counted in a single [synclet] log truncated: N further lines dropped line.

PIPELINE_LOG_ARCHIVE_BACKEND decides where the logs of finished jobs go:

Backend	Where logs of finished jobs live
none (default)	They stay in PostgreSQL until job retention deletes the job.
filesystem	Files under PIPELINE_LOG_ARCHIVE_DIR. Every server replica must see the same directory, so use a shared volume.
s3	Any S3-compatible bucket: AWS S3, MinIO, Cloudflare R2, Google Cloud Storage through its S3 interoperability endpoint (HMAC keys), or the Garage store bundled with the Helm chart. Set PIPELINE_LOG_ARCHIVE_S3_ENDPOINT for anything but AWS, and PIPELINE_LOG_ARCHIVE_S3_USE_PATH_STYLE=true for MinIO. Without static keys the default AWS credential chain is used (environment, IRSA, instance profile).
gcs	Google Cloud Storage through its native API. With PIPELINE_LOG_ARCHIVE_GCS_CREDENTIALS_FILE it uses that service account key; without it, Application Default Credentials (GKE Workload Identity, GOOGLE_APPLICATION_CREDENTIALS, or gcloud auth application-default login locally).

With an archive backend, a finished job’s logs move out of PostgreSQL into one gzipped NDJSON object per attempt, keyed logs/<workspace>/<connection>/<job>/<attempt>.ndjson.gz, and the UI reads them back from there. Job retention and workspace deletion remove the objects too.

The server logs which GCS credential source it uses at startup. Credentials are resolved on first use, so missing credentials show up as archive errors and in synclet_log_archive_failures_total, not as a startup failure.

Switching back to none leaves already archived logs where they are, but they can no longer be read from the UI.

All variables are listed under Environment Variables: Job Logs.

Prometheus Metrics

Synclet exposes a Prometheus-compatible metrics endpoint for integration with external monitoring systems like Grafana.

Metrics Endpoint

GET /metrics

The endpoint is served on the internal port (INTERNAL_HTTP_SERVER_ADDR, 8081 by default), not on the public UI port, and returns metrics in the Prometheus exposition format.

curl -s http://localhost:8081/metrics

Key Metrics

Metric	Type	Description
synclet_syncs_total	Counter	Total number of syncs by workspace, connection, and status.
synclet_sync_duration_seconds	Histogram	Duration of sync operations in seconds.
synclet_records_synced_total	Counter	Total records synced by workspace, connection, and direction.
synclet_bytes_synced_total	Counter	Total bytes synced by workspace and connection.
synclet_active_syncs	Gauge	Number of currently running syncs.
synclet_failed_syncs_total	Counter	Total number of failed syncs by workspace and connection.
synclet_pending_jobs	Gauge	Number of pending jobs in the queue.
synclet_connector_sync_duration_seconds	Histogram	Duration of sync operations by connector type.
synclet_log_archive_failures_total	Counter	Job attempts whose logs failed to archive, by archive backend (filesystem, s3, gcs).
synclet_log_archive_bytes_total	Counter	Total size in bytes of the job log objects written to the log archive.
synclet_log_lines_dropped_total	Counter	Job log lines dropped by the per-attempt line cap (PIPELINE_LOG_MAX_LINES_PER_ATTEMPT).

Kubernetes ServiceMonitor

With the Prometheus Operator, let the Helm chart create the ServiceMonitor. It scrapes /metrics on the internal Service port:

server:
  serviceMonitor:
    enabled: true
    interval: 30s
    labels:
      release: prometheus   # match your Prometheus selector

Health Endpoints

Synclet serves two probes on the internal port (8081 by default):

Endpoint	Returns 200 when
GET /live	The process answers HTTP.
GET /ready	Every health check passes: the database answers, background jobs have started and the event router is running (the last two only in processes that run them). Otherwise 503, with the failing checks in the JSON body.

curl -s http://localhost:8081/ready

Point load balancer health checks and Kubernetes probes at these endpoints. Images up to 0.4.0 serve only GET /health on the public port.

Next Steps

• Scheduling & Triggers — Configure when syncs run and how retries work.
• Notifications — Get alerted when syncs fail.
• Environment Variables — Configure metrics, log storage, and health check settings.