What's the difference between a source event, a delivery attempt, and a downstream action?

The source event is the thing that happened in Cornerstone PM — a task got assigned, a bid was declined. The delivery attempt is Cornerstone PM's HTTP POST of that event to your endpoint, logged with a timestamp and a response code. The downstream action is whatever your receiver does after it accepts the payload — fire a Twilio SMS, update a CRM record, kick off a voice call. A 200 response on the delivery attempt only confirms your endpoint acknowledged receipt. It says nothing about whether the downstream action actually ran or ran correctly.

Where do I check if a Cornerstone PM webhook actually fired?

Settings → Webhooks shows a delivery log for every configured endpoint: the event type, timestamp, target URL, response code, and the payload that was sent. If a teammate says a notification never arrived, check the log first. If an attempt is there with a 2xx response, the delivery succeeded and the problem is downstream, in your receiver or the service it calls. If the attempt is missing entirely, the event may not have fired, or the endpoint was unreachable before a retry resolved it.

Does Cornerstone PM retry a webhook automatically if delivery fails?

Yes. If your endpoint returns a non-2xx response or times out, Cornerstone PM queues an automatic retry with exponential backoff. You can see each attempt — original and retries — in the delivery log, along with the response code for each one. Retry logic covers getting the payload to your endpoint; it does not know whether your endpoint's downstream action (the SMS, the CRM update) succeeded, because that happens after your server returns its response.

Is Cornerstone PM's webhook delivery exactly-once?

No, and no webhook system that includes retries can honestly claim exactly-once delivery. A retry fires when Cornerstone PM doesn't get a clean 2xx response in time — which can happen even if your endpoint received the payload and is still processing it. That means a receiver can see the same event delivered more than once. Treating delivery as exactly-once and skipping duplicate handling is the single most common cause of a webhook integration that works in testing and misfires in production.

My receiver got the webhook but the automation didn't run. What should I check?

Separate the two systems. First confirm the delivery itself in the Cornerstone PM delivery log — response code, payload contents, timestamp. If that shows a clean 2xx, the problem lives entirely in your integration: your receiver's logs, the downstream API call it made (Twilio, your CRM, your voice vendor), and whether it handled the payload fields it expected. Cornerstone PM's delivery log only covers the hop from Cornerstone PM to your endpoint — it has no visibility into what your endpoint does next.

Should I manually repeat an action if I think a webhook failed?

Check the delivery log before repeating anything. If the delivery log shows the event was delivered with a 2xx response, manually repeating the action risks a duplicate — a second SMS, a second voice call, a second CRM update — stacked on top of one that already happened downstream. If the log shows no delivery attempt or a string of failed attempts with no eventual success, that's a real signal to investigate the endpoint and consider a manual trigger once you understand why it failed.

Who's responsible for deduplication — Cornerstone PM or my integration?

Your integration. Cornerstone PM's webhook layer guarantees a typed, signed, logged attempt to deliver each event, with automatic retry on failure. It does not guarantee the receiving system processes each event exactly once, because that depends entirely on how the receiver is built. A production-grade receiver checks an idempotency key — most teams use the event ID in the payload — before acting, so a redelivered event doesn't trigger a second downstream action.

A Webhook Failed: Trace the Delivery Before Repeating the Action — Cornerstone PM™ Blog

When a teammate says a notification never arrived, check the delivery log before you repeat the action. A clean 2xx delivery and a failed downstream automation are two different problems with two different owners — confusing them is how a retried webhook turns into a duplicate SMS, a double-booked voice call, or a CRM record updated twice.

Cornerstone PM's Foreman AI platform ships 37 named webhook events with typed payloads, HMAC-SHA256 signatures, delivery logs, and automatic retry. That infrastructure, added in the May 7 webhook release, gives builders and integration owners real visibility into what happened when an automation appears to have misfired. This post is a field guide to reading that visibility correctly — not another walk through the event catalog.

Why does a successful delivery not guarantee the automation ran?

A webhook delivery is one HTTP request: Cornerstone PM POSTs a signed, typed payload to your endpoint, and your endpoint returns a response code. When that response is 2xx, Cornerstone PM considers the delivery complete and logs it as such. Everything your receiver does after accepting that payload — parsing fields, calling Twilio, pushing a CRM update, kicking off a Bland or Retell voice call — happens in your integration code, outside anything Cornerstone PM can observe or log.

That boundary matters the moment something looks broken. A super says the sub never got a text when a task was assigned. The instinct is to assume the webhook failed and manually resend the notification. But the delivery log might show a clean 2xx response at the exact timestamp in question — meaning the event was delivered correctly, and the actual failure is in the receiver's Twilio call, not in Cornerstone PM's webhook pipeline. Repeating the action at that point doesn't fix anything; it just risks a second message once the real bug in the receiver gets fixed.

How do I trace a failed delivery before repeating an action?

Four checks, in order, separate a delivery problem from a downstream problem:

1. Confirm the delivery attempt

Did Cornerstone PM try to deliver this event?

Open Settings → Webhooks and find the event by type and approximate timestamp. If there's no delivery attempt at all, the event either didn't fire on the Cornerstone PM side or hasn't been triggered yet — that's a different problem than a failed delivery, and it points you back to the home, task, or vendor record instead of the webhook pipe.

2. Read the response code

Did the endpoint acknowledge it?

A 2xx response code means your endpoint accepted the payload — delivery succeeded from Cornerstone PM's side. A non-2xx response or a timeout means Cornerstone PM queued a retry with exponential backoff. Check whether a later attempt in the same log eventually got a 2xx. If it did, the event was delivered; it just took more than one try.

3. Separate delivery from downstream work

Did the receiver's action actually happen?

A successful delivery only proves your server returned a 2xx — not that the SMS sent, the CRM updated, or the voice call connected. That logic lives in your receiver, after it accepts the payload. If the delivery log is clean but nothing downstream happened, the investigation moves to your integration code and the third-party service it calls, not back to Cornerstone PM.

4. Check for a duplicate before repeating anything

Could this already have happened once?

Retries mean a receiver can see the same event more than once. Before manually re-triggering a notification or re-running an action, check whether the event ID in the payload was already processed. A receiver that keys off the event ID for idempotency won't double-fire on a legitimate retry — one that doesn't will.

What does the Cornerstone PM delivery log actually show?

In Settings → Webhooks, every configured endpoint has a delivery log: event type, timestamp, target URL, response code, and the exact payload sent. This is the first place to look, and usually the only place you need to look to answer "did this fire, and did my endpoint accept it." It does not — and cannot — tell you whether your receiver's downstream call to Twilio, your CRM, or a voice vendor succeeded, because that logic runs on your server after the delivery completes. If you need visibility into that half of the chain, it has to be logged in your own integration.

For a full rundown of the event catalog, payload typing, and the HMAC signature verification that confirms a request actually came from Cornerstone PM, see the 37 webhook events overview. This post assumes that infrastructure exists and focuses specifically on reviewing a delivery after something looks wrong.

Why automatic retry doesn't mean exactly-once delivery

When an endpoint returns a non-2xx response or times out, Cornerstone PM queues a retry with exponential backoff rather than dropping the event. That's the right behavior for a momentary outage — a redeploy, a cold start, a brief network blip — but it has a side effect worth planning for: a receiver can end up seeing the same event delivered more than once. If your endpoint accepted the payload and started processing it, but was slow enough that Cornerstone PM didn't see the 2xx in time, a retry can arrive on top of work that's already underway.

This isn't a defect in the retry system — it's the standard tradeoff every at-least-once delivery system makes, and it's the reason exactly-once guarantees are rare in real webhook infrastructure. The responsibility for handling it sits with the integration owner, not the platform: a receiver that checks the event ID in the payload against what it's already processed won't double-fire a Twilio SMS or a CRM update on a legitimate retry. A receiver that skips that check will.

A quick before-you-repeat-it checklist

Before manually re-triggering a notification, a voice call, or a CRM push, confirm:

The delivery log shows either no successful attempt, or a string of failures with no eventual 2xx — not just a single retry that later succeeded.
You've checked your own receiver's logs for the same timestamp, not just Cornerstone PM's delivery log.
The event ID from the payload hasn't already been processed by your receiver, so a manual retrigger doesn't stack on top of a delivery that actually succeeded.
If the fix is on your end — a receiver bug, a downstream API outage — you're fixing that, not treating Cornerstone PM's delivery log as the source of the problem.

Builders running automation on top of Cornerstone PM's API and webhook layer get the visibility to answer these questions in minutes instead of guessing. The delivery log tells you what Cornerstone PM did. Your own receiver logs tell you what happened next. Keeping those two investigations separate is what keeps a single failed notification from turning into a duplicate one.

Build automations on a webhook layer you can actually debug.

Cornerstone PM ships 37 named webhook events with HMAC signatures, per-event delivery logs, and automatic retry — the visibility builders need to trust their automation stack, not just enable it.

Request Early Access →

A Webhook Failed: Trace the Delivery Before Repeating the Action