Sales ops asks why an account they created three weeks ago still isn’t in the warehouse. You open the dashboard for the sync. Error count: zero. Every day, flat, zero. The alarm is not firing.<\/p>\n\n\n\n
Then you check the invocation count and it is also zero, and has been since the day somebody disabled an EventBridge rule while cleaning up a different stack. The job has not run in three weeks. It never errored because it never started.<\/p>\n\n\n\n
This is the shape of almost every integration monitoring failure: a healthy graph and a stopped job produce identical output.<\/strong> Zero errors is what success looks like and it is also what absence looks like, and if the only thing you measure is failure, the two are indistinguishable.<\/p>\n\n\n\n This is about how to monitor Salesforce integrations<\/strong> so that stopping is as loud as breaking. Four signals worth emitting, how to get them into CloudWatch cheaply, the alarm configuration that actually fires, and what belongs on a Grafana dashboard once you have them.<\/p>\n\n\n\n Most integration monitoring stops at errors and duration, because those come free from Lambda or your container platform. Both are worth having and neither answers the question anybody actually asks, which is “is the data right”.<\/p>\n\n\n\n The four that do:<\/p>\n\n\n\n Errors are a fifth, and the least interesting, because errors are the failure mode that already announces itself.<\/p>\n\n\n\n Emit a metric on every successful completion. A single count, value 1. Then alarm when it stops arriving.<\/p>\n\n\n\n The trap is in the CloudWatch defaults. So heartbeat alarms need The robust version uses metric math to turn absence into a real zero, so there is no missing data to interpret:<\/p>\n\n\n\n Then do the thing everyone skips: disable the schedule in a test account and confirm the alarm actually goes red. An untested alarm is a belief, not a control.<\/p>\n\n\n\n A job can complete successfully and process nothing. A credential with the wrong field-level permissions, a filter that silently matches nothing, a watermark that got written before the data landed: all of these produce a clean run and an empty result.<\/p>\n\n\n\n Volume<\/strong> is the count of records read and written per run. Alarming on it is harder than liveness because the right number varies: a quiet Sunday legitimately looks like a broken Tuesday. Two approaches that work. Use CloudWatch anomaly detection, which learns the daily and weekly shape and alarms on departures from it. Or set a crude floor that only catches the catastrophic case, which is usually zero, and accept that you will not catch a fifty percent drop.<\/p>\n\n\n\n I would start with the crude floor. It is five minutes of work and catches the failure that actually happens.<\/p>\n\n\n\n Freshness<\/strong> is the better metric and almost nobody emits it. At the end of each run, query the destination for the newest record’s modified timestamp, subtract it from now, and publish the difference in seconds. That single number answers the business question directly: how far behind Salesforce are we right now?<\/p>\n\n\n\n It also collapses several failure modes into one signal. A stopped job, a job that runs but writes nothing, a job stuck retrying, a job silently filtered down to zero rows: all of them show up as lag climbing. If you only add one metric from this post, add this one.<\/p>\n\n\n\n Your org has a daily API allowance shared across every integration touching it. Exceeding it does not just break your sync; it breaks marketing automation, support tooling, and whatever else somebody connected two years ago.<\/p>\n\n\n\n Enforcement is initially soft, and then it is not: past a protection threshold, calls come back as 403 with The good news is that this costs nothing to observe. Salesforce returns your current consumption on ordinary REST responses in a header, so you get it on calls you were making anyway:<\/p>\n\n\n\n For a fuller picture, the Graph consumption by integration if you can attribute it. The conversation about which team is burning the allowance goes very differently when there is a chart.<\/p>\n\n\n\n You can call The better default is Embedded Metric Format: write structured JSON to stdout and CloudWatch extracts the metrics from your logs. No API call, no added latency, and the log line stays queryable in Logs Insights alongside the metric.<\/p>\n\n\n\n Note what is a dimension and what is not. CloudWatch dashboards are fine and Grafana is better for this, for three reasons: you can put Salesforce metrics next to your warehouse and application metrics on one screen, the alerting is more expressive, and non-engineers will actually open it.<\/p>\n\n\n\n Add CloudWatch as a data source using an IAM role rather than access keys, scoped to What goes on the dashboard, in order down the page:<\/p>\n\n\n\n One dashboard, one screen, no scrolling. A dashboard nobody can read at a glance during an incident is decoration.<\/p>\n\n\n\n Decide deliberately where alerting lives. CloudWatch alarms are more reliable, because they keep working when Grafana is down, and Grafana alerts are more flexible and can span data sources. My default is CloudWatch for the small number of alerts that page someone, and Grafana for everything informational.<\/p>\n\n\n\n Three things that separate a useful alert from noise. Alarm on the symptom, not the cause: “Opportunity data is more than two hours stale” is actionable in a way “Lambda errors greater than zero” is not. Put the runbook link in the alarm description, since that field ends up in the notification and is the only documentation anybody reads at midnight. And use composite alarms to suppress the cascade, so a Salesforce outage produces one page rather than nine.<\/p>\n\n\n\n Almost certainly Freshness: how old the newest record on the destination side is. It catches stopped jobs, empty runs, stuck retries and silent filtering with one number, and it is the only one of these metrics a non-engineer can interpret.<\/p>\n\n\n\n Grafana if you already run it, because you can put Salesforce, warehouse and application metrics on one screen. CloudWatch if you do not, because a second system to operate is not free. Either way keep the paging alarms in CloudWatch so they survive Grafana being down.<\/p>\n\n\n\n Only if you make them so. Cost scales with unique name-and-dimension combinations, so a handful of metrics dimensioned by integration name is negligible. Adding a run ID or record ID as a dimension is how the bill grows without anyone noticing.<\/p>\n\n\n\n Monitor the destination instead. A scheduled job that queries the target for the newest record’s timestamp and emits it as a freshness metric works regardless of what wrote the data, and it is arguably a better test because it measures the outcome rather than the process.<\/p>\n\n\n\n Absence of failure is not evidence of success. An integration that stopped produces exactly the same error graph as one working perfectly, and every default in your monitoring stack is tuned to stay quiet when data stops arriving rather than to shout about it.<\/p>\n\n\n\n So measure the thing you actually care about. Not “did it error” but “how stale is the data right now”, alarmed in a way that fires on silence, and tested by deliberately breaking it. Everything else on the dashboard is supporting evidence.<\/p>\n\n\n\n Integration monitoring tends to get added after the first silent failure, which is one failure too late. Work I take on:<\/p>\n\n\n\n Tell me how you would currently find out that a sync stopped, and I will tell you how long it would take.<\/p>\n\n\n\nFour signals, not one<\/h2>\n\n\n\n
\n
Liveness: the alarm that has to fire on silence<\/h2>\n\n\n\n
TreatMissingData<\/code> has four settings, and the default is missing<\/code>, which sends the alarm to INSUFFICIENT_DATA<\/code> when nothing arrives. That state is not ALARM<\/code>. Nothing pages. Your dashboard shows a grey alarm that most people read as “fine”.<\/p>\n\n\n\nbreaching<\/code>. That much is standard advice. Here is the part that is not: even with breaching<\/code> set, a heartbeat alarm can still fail to fire.<\/strong> CloudWatch evaluates over a range wider than your evaluation periods, and if it finds any real data point in that wider range, those override the missing ones. On a job that runs hourly, a successful run from earlier can keep the alarm quiet through several missed runs.<\/p>\n\n\n\naws cloudwatch put-metric-alarm \n --alarm-name \"opportunity-sync-not-running\" \n --alarm-description \"No completed run in the last 90 minutes\" \n --comparison-operator LessThanThreshold \n --threshold 1 \n --evaluation-periods 1 \n --treat-missing-data breaching \n --alarm-actions \"$SNS_TOPIC_ARN\" \n --metrics '[\n {\n \"Id\": \"runs\",\n \"MetricStat\": {\n \"Metric\": {\n \"Namespace\": \"SalesforceSync\",\n \"MetricName\": \"RunCompleted\",\n \"Dimensions\": [{\"Name\": \"Integration\", \"Value\": \"opportunity-sync\"}]\n },\n \"Period\": 5400,\n \"Stat\": \"Sum\"\n },\n \"ReturnData\": false\n },\n {\n \"Id\": \"filled\",\n \"Expression\": \"FILL(runs, 0)\",\n \"ReturnData\": true\n }\n ]'<\/code><\/pre>\n\n\n\nFILL(runs, 0)<\/code> substitutes a zero wherever the metric has no data point, so the alarm always has something real to compare against the threshold. The window is deliberately longer than the schedule: an hourly job gets ninety minutes, so one late run does not wake anybody.<\/p>\n\n\n\nVolume and freshness: is the data actually moving<\/h2>\n\n\n\n
Budget: watch the Salesforce allowance<\/h2>\n\n\n\n
REQUEST_LIMIT_EXCEEDED<\/code> until the rolling window drains. By that point you are in an incident that spans several teams.<\/p>\n\n\n\n# Sforce-Limit-Info: api-usage=1212\/15000\n#\n# Free: no extra API call, which matters when the thing you are\n# measuring is an API budget. Add real error handling before\n# shipping this; the header is not guaranteed on every response.\nraw = response.headers.get(\"Sforce-Limit-Info\", \"\")\nused, allowed = (int(v) for v in raw.split(\"api-usage=\")[1].split(\"\/\"))\nemit(\"ApiUsagePercent\", used \/ allowed * 100)<\/code><\/pre>\n\n\n\n\/services\/data\/vXX.X\/limits<\/code> endpoint returns every allocation in the org, including DailyApiRequests<\/code> with its max and remaining values. It needs the View Setup and Configuration permission and the numbers lag by a few minutes. Poll it on a schedule rather than per request, and alarm on percentage consumed rather than absolute calls, so the alarm survives a licence change.<\/p>\n\n\n\n
\n\n\n\nGetting the metrics in without a bill shock<\/h2>\n\n\n\n
PutMetricData<\/code> directly, and it works, and it is a synchronous API call in the hot path of your job that can fail or add latency. Custom metrics are also charged per metric per month, and a metric is every unique combination of name and dimensions, so a dimension with high cardinality gets expensive quietly.<\/p>\n\n\n\n{\n \"_aws\": {\n \"Timestamp\": 1700000000000,\n \"CloudWatchMetrics\": [{\n \"Namespace\": \"SalesforceSync\",\n \"Dimensions\": [[\"Integration\"]],\n \"Metrics\": [\n { \"Name\": \"RunCompleted\", \"Unit\": \"Count\" },\n { \"Name\": \"RecordsWritten\", \"Unit\": \"Count\" },\n { \"Name\": \"SourceLagSeconds\", \"Unit\": \"Seconds\" },\n { \"Name\": \"ApiUsagePercent\", \"Unit\": \"Percent\" }\n ]\n }]\n },\n \"Integration\": \"opportunity-sync\",\n \"RunId\": \"a41c9f\",\n \"RunCompleted\": 1,\n \"RecordsWritten\": 4127,\n \"SourceLagSeconds\": 312,\n \"ApiUsagePercent\": 8.1\n}<\/code><\/pre>\n\n\n\nIntegration<\/code> is a dimension because it has a handful of values and you want to alarm per integration. RunId<\/code> is a plain field: searchable in the logs, and not a dimension, because making it one would create a new metric on every run. That distinction is the whole cost story.<\/p>\n\n\n\nGrafana on top<\/h2>\n\n\n\n
cloudwatch:GetMetricData<\/code>, cloudwatch:ListMetrics<\/code> and the Logs Insights permissions if you want log panels. One honest cost note: Grafana queries CloudWatch through the metric data API, which is billed per metric requested, so a busy dashboard on a short refresh interval is a real line item. Set a sane refresh, avoid auto-refresh on wall displays, and use the caching in Grafana’s CloudWatch data source.<\/p>\n\n\n\n\n
Alerts people don’t ignore<\/h2>\n\n\n\n
Common mistakes<\/h2>\n\n\n\n
\n
TreatMissingData<\/code> at its default on a heartbeat alarm.<\/li>\nbreaching<\/code> and assuming that is sufficient, without handling the evaluation range.<\/li>\nPutMetricData<\/code> synchronously in the job’s critical path.<\/li>\nBest practices<\/h2>\n\n\n\n
\n
breaching<\/code> plus FILL()<\/code>, and a window longer than the schedule.<\/li>\n
\n\n\n\nFAQ<\/h2>\n\n\n\n
Why didn’t my CloudWatch alarm fire when the job stopped?<\/h3>\n\n\n\n
TreatMissingData<\/code>. The default sends the alarm to INSUFFICIENT_DATA<\/code>, which is not ALARM<\/code> and pages nobody. Set it to breaching<\/code>, and wrap the metric in FILL()<\/code> so there is no missing data for CloudWatch to reinterpret.<\/p>\n\n\n\nWhat’s the single most useful metric to add?<\/h3>\n\n\n\n
CloudWatch dashboards or Grafana?<\/h3>\n\n\n\n
Will custom metrics be expensive?<\/h3>\n\n\n\n
How do I monitor a third-party connector I can’t add code to?<\/h3>\n\n\n\n
\n\n\n\nThe one thing to remember<\/h2>\n\n\n\n
Want this built properly?<\/h2>\n\n\n\n
\n