5.20 Release notes

Upgrade guides

• Upgrading on IIS
• Upgrading on Kubernetes

Release date

Cinchy v5.20 was released on June 2, 2026.

Upgrade duration

The v5.20 model upgrade can take up to 30 minutes to complete due to the volume of model changes:

• Schema updates and index creation on Execution Log and Execution Errors.
• 5 new tables provisioned for the Observability Dashboard (sync groups, group members, SLA definitions, health snapshots, baseline metrics), plus 13 new columns on Event Listener State for real-time listener metrics.
• 3 new tables provisioned for the Email Notification Service (Notification Outbox, Notification Config, Notification Branding), plus the notification@cinchy.com user, the cinchy_notification integrated client, and the Notifications Enabled System Property.

Plan your upgrade window accordingly.

Access for the new v5.20 features

• The Observability Dashboard is restricted to members of the Cinchy Administrators User Group — both the dashboard view and its underlying tables are administrator-only.
• The Email Notification Service also defaults to Cinchy Administrators, but admins can delegate management of notification rules and branding to non-admin users or groups by granting per-table entitlements (see the access section for recommended permissions per table).

Enhancements

Observability Dashboard

Cinchy v5.20 introduces a built-in Observability Dashboard that provides real-time monitoring and health visibility for batch and real-time data syncs. Users with Admin access can open it from Profile > Dashboard or by visiting /admin/observability.

---

How it works

Cinchy scores your syncs from the data already in the Execution Log and listener state, then surfaces health, regressions, and stalled real-time syncs in a single view.

---

Key capabilities

• Health scores per sync group with color-coded 0-100 scoring based on success rates, execution timing, and critical sync status.
• Correlated failure detection that clusters syncs failing around the same time to surface shared root causes.
• Execution time trending with a 30-day rolling baseline comparison to detect performance regressions.
• Real-time listener monitoring with throughput metrics, stale listener detection, and queue depth forecasting.
• Data freshness and SLA tracking that flags tables exceeding configured staleness thresholds.
• Real-Time Sync Status panel showing per-listener status (Caught Up, Recovering, or Stalled) with estimated backlog and catch-up time.
• Platform-specific diagnostics including Service Broker queue health [IIS only] [SQL Server only] and Kafka consumer lag [K8s only].

Recommended: Run platform maintenance regularly

The dashboard queries the Execution Log table heavily, and unbounded growth degrades performance over time. We strongly recommend running Cinchy's platform maintenance on a regular cadence so old Execution Log rows are cleaned up. See Performance recommendations in the Observability Dashboard guide for details.

---

Environment-specific behavior

Behavior differs slightly by deployment. Select your environment below.

IIS + SQL Server

Service Broker queue health diagnostics require the VIEW SERVER STATE permission on the database login used by Cinchy.

Kubernetes + Kafka

Kafka consumer lag metrics are written by the Connections worker (KafkaBatchProcessor) via the EventSyncMetricsService after each successful batch, and persisted to the new Kafka Lag, Kafka Committed Offset, and Kafka End Offset columns on Event Listener State. Until those are populated, the dashboard derives lag estimates from listener timestamps.

PostgreSQL

All dashboard features are supported except Service Broker diagnostics, which are SQL Server only.

What is provisioned on upgrade

The model upgrade automatically creates:

• 5 new tables in the Cinchy domain for sync groups, group members, SLA definitions, health snapshots, and baseline metrics.
• 2 saved queries powering maintenance workflows.
• 2 data sync configurations for maintenance workflows.
• Performance indexes on the Execution Log and Execution Errors tables.
• 13 new columns on Event Listener State for real-time listener metrics (10 counter columns plus 3 Kafka offset columns: Kafka Lag, Kafka Committed Offset, Kafka End Offset).

---

New maintenance CLI command

A new maintain-observability CLI verb automates the daily maintenance sequence: refreshing baseline metrics, calculating health scores, cleaning up old snapshots, and resetting real-time event counters. Schedule this command to run daily (recommended at 02:00 UTC) to keep dashboard data current.

Cinchy.Connections.CLI.exe maintain-observability \
  -s cinchy.example.com/Cinchy \
  --https \
  --pat "YOUR_PERSONAL_ACCESS_TOKEN" \
  --retention-days 90

---

Email Notification Service

Cinchy v5.20 introduces the Email Notification Service, a standalone service that sends automated, branded email alerts when data syncs, event listeners, or automations fail, succeed, or run longer than expected. It is disabled by default and opt-in: on Kubernetes, set "notification_enabled": "true" in your deployment.json; on IIS, opt in by deploying the Notification service as an IIS sub-application. See the v5.20 upgrade guides for full setup instructions.

---

How it works

Syncs and listeners notify the service by webhook; automations are detected by background monitors. Every notification is persisted to a durable outbox before sending, so no email is lost even if a pod restarts mid-send.

---

What triggers an email

Failure

Fires when

A Batch Sync, Event Sync, or Automation ends in a failure state.

Enabled by default on every Notification Config row (Notify On Failure). The email includes the artifact name, execution details, and an error summary.

Success

Fires when

A Batch Sync or Automation completes successfully.

Off by default — turn on Notify On Success per artifact when a team genuinely wants confirmation. (Not available for Event Syncs.)

Long-running

Fires when

A Batch Sync or Automation stays in the Running state longer than the configured threshold.

Off by default — set Notify On Long Running and a Long Running Threshold Minutes on the row. Detected by background monitors. (Not applicable to Event Syncs.)

---

Choose your email provider

Only one provider is active per deployment, configured in appsettings.json.

SMTP

For on-prem deployments, Office 365, or any SMTP server. Supports TLS modes, authentication, custom EHLO domain, and certificate validation control.

AWS SES

For cloud deployments on AWS. Uses IAM role authentication (IRSA on EKS) — no static credentials required — with optional delivery tracking and bounce handling.

Azure Communication Services

For cloud deployments on Azure. Supports connection-string auth or managed identity (DefaultAzureCredential).

Microsoft Graph

For Microsoft 365 environments where SMTP submission is disabled. Sends via the Graph API using a Microsoft Entra app registration with the Mail.Send application permission.

All capabilities at a glance

Capability	What it does
Three artifact types	Batch syncs, event listeners, and automations under a single configuration model.
Trigger type filtering	Independently enable Failure, Success, and LongRunning per artifact via [Cinchy].[Notification Config].
Flexible recipient routing	Per-artifact recipients, Cinchy Group resolution, CC/BCC (incl. dedicated BCC groups for compliance), Reply-To, From override, and priority levels.
Server-side cooldown	A per-(artifact, trigger type) cooldown that survives pod restarts, suppressing notification storms even across crashes.
Branded templates	Default Cinchy branding out of the box; per-client branding via [Cinchy].[Notification Branding] (logo from [Cinchy].[Files], color from [Cinchy].[System Colours]).
Multiple providers	SMTP, AWS SES, Azure Communication Services, and Microsoft Graph.
Reliable delivery	Durable outbox with exponential-backoff retries and stale-claim recovery — no email lost.
Safety features	Allowed recipient-domain allow-lists for non-production, plus client-side rate limiting to stay within provider quotas.

Provisioned automatically on upgrade

The upgrade creates everything the service needs: the Notification Outbox, Notification Config, and Notification Branding tables, the notification@cinchy.com user, the cinchy_notification integrated client, and the Notifications Enabled System Property (the global kill switch).

To start using the service, see the Email Notification Service documentation for setup instructions and a full feature guide. Deployment steps are covered in the v5.20 (Kubernetes) and v5.20 (IIS) upgrade guides.

---

Cinchy MCP — new create_table tool

Cinchy v5.20 adds a new tool, create_table, to the Cinchy MCP Server. AI assistants connected to your environment can now create new Cinchy tables in addition to reading and modifying data.

Your prompt

"Create a Customers table in the Sales domain with columns Name (text, 200), Tier (choice: Gold, Silver, Bronze), Signup Date (date), and Active (yes/no)."

The AI calls create_table with the domain, table name, and a column array. The tool supports the five core Cinchy column types — Text (with optional max_length), Number, Yes/No, Date, and Choice (with a required choices array) — and the operation runs under your identity, so existing row- and column-level entitlements are enforced.

Parameter	Required	Description
domain	Yes	Domain the new table belongs to.
table_name	Yes	Name of the new table.
columns	Yes	Array of column definitions. Each column has name and type, plus max_length for Text and choices for Choice.

This brings the MCP server's total tool count to 22. See the Cinchy MCP Server guide for the full catalog and setup instructions.