salesloft-performance-tuning

v2026.09.24

Analyze and improve measured Salesloft sync latency and throughput with cursor polling, bounded page size, safe concurrency, caching, and correctness checks. Use when an integration is slow or falling behind. Trigger with "Salesloft performance", "speed up Salesloft sync", or "Salesloft cursor poller".

GitHub
Install command
npx skhub add jeremylongshore/salesloft-performance-tuning
Markdown
SKILL.md

Salesloft Sync Performance Tuning

Overview

This skill optimizes one measured Salesloft path without trading away completeness or tenant isolation. It treats deep pagination and uncontrolled concurrency as cost and correctness risks.

Prerequisites

  • A named operation, team, dataset size, and service-level objective
  • Baseline latency, pages, endpoint cost, remaining budget, retries, and lag
  • Correctness assertions and replayable fixtures
  • Durable cursor and destination transaction boundary

Tool Discipline

Use Read, Glob, and Grep to locate pagers, caches, concurrency, checkpoints, and metrics. Use WebFetch only for current official Salesloft contracts. Use Write or Edit after the baseline and target path are confirmed.

Current Contract

  • Supported list endpoints generally page from 1 with up to 100 records per page.
  • Deep page indices incur higher documented cost, so full scans degrade shared team capacity.
  • Salesloft's efficient polling pattern sorts updated_at ascending and persists a microsecond-precision cursor.
  • A production poller must handle overlap and duplicate processing safely.
  • Actual response headers, not assumed request counts, measure endpoint cost.

Authentication

Use the existing tenant-bound read credential. Performance work must not broaden scopes or mix caches, cursors, or limiters between teams.

Instructions

  1. Measure the slow path with record count, page count, p50/p95 latency, endpoint cost, remaining budget, and lag.
  2. Confirm the endpoint's supported filters and sort fields.
  3. Replace repeated deep scans with an updated_at cursor, ascending order, page size up to 100, and a deliberate overlap window.
  4. Persist destination data and cursor atomically; deduplicate by stable resource ID and content fingerprint.
  5. Add bounded per-team concurrency and cache only data with explicit freshness rules.
  6. Load-test with fixtures, then run a bounded canary against an approved team.
  7. Compare before/after performance and reconciliation counts before rollout.

Approval Boundaries

Do not raise concurrency, remove overlap, skip reconciliation, or cache prospect data beyond policy merely to improve latency.

Output

Return baseline, bottleneck, change, cursor and cache rules, rate impact, correctness comparison, canary result, and measured improvement.

Error Handling

ConditionResponse
Records missingRoll back and widen overlap or repair cursor logic.
Duplicate side effectsMake the consumer idempotent before resuming.
Endpoint cost risesReduce deep pages or concurrency and inspect actual headers.
Cache crosses teamPurge affected entries and investigate tenant isolation.

Examples

The example below shows the minimum redacted evidence expected from a successful invocation of this operator workflow.

lag=18m->3m; p95=2.4s->0.8s; reconciled=100%; endpoint-cost=-63%

Resources

Discovery
Tags

No tags published for this skill.

Version
Latest version metadata

Version

v2026.09.24

Published

Sep 24, 2026

Category

Uncategorized

License

MIT

Source path

skills/.curated/salesloft-performance-tuning

Default branch

main

Latest commit

e5a6c3b

Tree SHA

c2dc8e8