REDCap Alerts and Notifications: Triggers and Scheduling

REDCap’s Alerts & Notifications module sends an automated message — almost always email — when a condition on a record becomes true, either the instant it’s saved or on a schedule tied to a date already stored on that record. It sits alongside Automated Survey Invitations in REDCap’s automation toolkit, but where an invitation moves a participant into a survey, an alert is aimed at a person with a plain notification: a query needs resolving, a safety threshold has been crossed, a visit window is closing. This guide covers how a single alert is assembled — the trigger condition, the schedule, the recipient, and the message — and where the module is commonly used for adverse-event and data-query workflows.

REDCap (Research Electronic Data Capture) is developed and distributed through the non-profit REDCap Consortium rather than sold as a commercial product with public pricing; Alerts & Notifications is standard project functionality, not a paid add-on. See CASRAI’s REDCap dictionary entry for the platform overview and Is REDCap HIPAA-Compliant? for what the platform’s compliance framing does and doesn’t guarantee automatically for the messages this module sends.

How an alert is assembled

Alerts & Notifications is its own application in a project’s left-hand menu, separate from Online Designer, where instruments and fields themselves are built. Every alert is made of the same four parts:

• A trigger condition. Alerts reuse the same logic syntax as everywhere else in REDCap — see CASRAI’s guide to REDCap branching logic for the comparison-operator syntax. An alert’s condition can be as simple as a single field equalling a value, or a combined expression across several fields.
• A schedule. Send immediately once the condition is met, or defer to a specific point relative to a date field on the record — covered below.
• One or more recipients. A fixed address typed into the alert, an address pulled from a field on that record (a participant’s own email, a site coordinator’s, a PI’s), or a REDCap user holding a specific project role.
• A message. Subject and body text that can pipe in field values from the record, the same way any other REDCap text field can — see below.

Immediate vs. scheduled sending

An alert can fire in one of two ways:

• Immediately, the moment the trigger condition evaluates true on a saved record — the closest REDCap gets to a real-time push, useful for anything that needs eyes on it right away (an adverse-event severity field crossing a threshold, for example).
• On a schedule, relative to a date or datetime value already stored on that record — a fixed number of days, weeks, or months before or after a reference date such as an enrollment date, a scheduled visit date, or the date a query was opened. This is what lets a reminder go out a set interval after a real study event rather than only when someone happens to check the project, the same date-relative mechanism Automated Survey Invitations uses for reminder emails.

Scheduled alerts are picked up by REDCap’s own alert-processing behind the scenes rather than dispatching at the literal instant a date rolls over — expect them within the same kind of processing window as REDCap’s other date-triggered automation, not a guaranteed-to-the-second delivery. Design around “sometime that day,” not “at 12:00:01am.”

The message body: piping and smart variables

An alert’s subject and body accept the same square-bracket piping syntax covered in CASRAI’s guide to piping in REDCap: wrap a variable name in brackets, [variable_name], and REDCap substitutes the record’s actual stored value when the alert sends. A safety-monitor alert can read “Adverse event reported for [record_id]: [ae_severity], onset [ae_onset_date]” and arrive with the real values filled in, rather than requiring the recipient to open the record to see what changed. The same event-name-prefix rule from that guide applies in longitudinal projects: a bare [variable_name] only reads the current event, so pulling a value logged at a different event needs the [unique_event_name][variable_name] form.

One-time vs. repeating, and checking what actually sent

Each alert can be limited to fire once per record, or left to fire again whenever its condition is re-met on a later save — the setting that determines whether a reminder repeats (a weekly nudge until a query is resolved) or fires exactly once (a single notification the day an adverse event is logged). REDCap keeps a project-level log of an alert’s send history, which is the way to confirm an alert actually went out rather than assuming it did because the condition looks satisfied — a silent misconfiguration elsewhere (see below) can leave a condition technically met with nothing ever sent.

One REDCap behavior worth planning around: an alert generally only starts evaluating go-forward from whenever it’s created and activated. Records that already met the condition before the alert existed are commonly reported as not triggering it retroactively until something about that record is saved again — don’t assume activating a new alert will immediately notify on a backlog of already-qualifying records without a resave.

A practical use case: adverse-event and query workflows

Two patterns cover most of how research teams actually use this module:

• Immediate escalation on a safety signal. A field capturing adverse-event severity, or a serious-adverse-event checkbox, triggers an immediate alert to the study’s safety monitor or PI the moment a coordinator saves the form — closing the gap between a coordinator entering data and someone with oversight responsibility actually seeing it.
• Scheduled reminders on open data queries. A query-status field that stays “open” past a set number of days after the query date triggers a scheduled reminder to the site coordinator responsible for resolving it, repeating until the field changes to “resolved.” This is the same date-relative-plus-repeat mechanism described above, applied to query aging instead of visit scheduling.

Both patterns lean on the trigger condition doing real work, not just existing — get the branching-logic expression wrong and the alert either never fires or fires on the wrong records, silently either way.

Common failure points

• A trigger condition that never evaluates true. The same silent-failure pattern documented in CASRAI’s branching logic guide applies here: a typo’d variable name, a mismatched checkbox (code) reference, or a logic error means the condition simply never resolves to true, and REDCap does not surface an error for it — the alert just never sends. Test the condition against a real record before trusting it in production.
• A recipient field with no value. If the alert pulls its recipient from a field on the record and that field is blank for a given record, there’s no address to send to and no visible warning that a notification was skipped.
• A schedule anchored to an empty date field. A scheduled alert relative to a date field that hasn’t been filled in yet has nothing to calculate a send time from, so it simply never queues for that record until the date field is populated.
• Assuming activation is retroactive. As above — a newly built alert typically won’t reach back and notify on records that already met the condition before the alert was turned on.

Frequently asked questions

Can an alert go to a participant instead of a staff member?

Yes, as long as the record has a field holding the participant’s own email address — the alert can pull a recipient address from any field the same way it would a staff member’s, subject to the same “field must actually have a value” caveat above.

How is an alert different from an Automated Survey Invitation?

An Automated Survey Invitation has one job: get a participant into a specific survey instrument. An alert is general-purpose — it sends a plain message built from any trigger condition and any piped field values, to any recipient, and isn’t tied to moving someone into a survey at all. Both share the date-relative scheduling mechanism and the branching-logic condition syntax, which is why they’re easy to confuse.

Does an alert require the record to be part of a survey?

No — alerts trigger off data-entry forms as well as surveys. The trigger condition evaluates against whatever data is stored on the record regardless of whether it was entered by a participant through a survey or by staff through a data-entry form.

Related REDCap and survey-platform guides

• REDCap Survey Queue and Automated Invitations — the sibling automation feature for getting participants into surveys, versus alerts’ general-purpose notifications.
• REDCap Branching Logic: Syntax, Testing, and Common Errors — the condition syntax an alert’s trigger reuses.
• Piping in REDCap: Injecting Field Values Into Text — the syntax an alert’s message body reuses to include real field values.
• REDCap Randomization Module: Allocation Tables and Stratification — another Applications-menu module commonly combined with alerts in clinical-trial builds.
• Is REDCap HIPAA Compliant? — what to configure before routing PHI-adjacent content through an automated message.
• The REDCap API: Tokens, Exports, and Automating Data Pulls — for moving data out of REDCap programmatically rather than notifying about it in place.
• Qualtrics vs REDCap for Academic & Clinical Research — how REDCap’s automation feature set compares to the other major academic survey platform.
• REDCap (Research Electronic Data Capture) — the platform-level dictionary entry.