REDCap Repeating Instruments and Repeating Events

REDCap gives a project two different ways to let a data point recur an indeterminate number of times: a repeating instrument, where one form on a record can be filled out again and again, and a repeating event, where an entire scheduled bundle of forms (an event, in a longitudinal project) can recur. They solve the same underlying problem — “we don’t know in advance how many times this will happen” — but they attach to different levels of a project’s structure, and picking the wrong one produces a data model that’s awkward to analyze later. This guide covers what each does, how to turn it on, how the resulting data actually looks in an export, and what that means for analysis.

For REDCap generally, see the REDCap dictionary term. For the underlying field-definition table both features sit on top of, see REDCap Data Dictionary: Structure, Editing, and Moving a Project.

The default: one instrument, one fill, per record or per event

Without repeating turned on, every instrument in a classic (non-longitudinal) project can be filled out exactly once per record. In a longitudinal project — one with the “Enable longitudinal data collection with defined events” setting turned on — every instrument assigned to an event can be filled out exactly once per record per event. Neither of those is enough for data that genuinely recurs within a single record without a fixed, known count: multiple concurrent medications, a variable number of adverse events, repeated lab draws that aren’t tied to a scheduled visit, or an unscheduled follow-up encounter that might happen zero, one, or several times. That’s what repeating instruments and repeating events exist to handle.

Repeating instruments

A repeating instrument is a single form marked so it can be completed more than once for the same record (in a classic project) or more than once within the same event (in a longitudinal project). Each completion creates a new instance, numbered sequentially (1, 2, 3…). It’s turned on in Project Setup: classic projects have a “Repeatable Instruments” section listing every instrument with a checkbox; longitudinal projects configure it on the “Designate Instruments for My Events” grid, where each instrument can be marked repeating independently for each event it’s assigned to.

Repeating instruments are the right fit when it’s a specific form, not the whole scheduled visit, that recurs — a Concomitant Medications log, an Adverse Event form, a Lab Result form filled in every time a specimen comes back, all sitting inside a visit (or a whole classic project) that itself only happens once.

Repeating events

A repeating event is only available in longitudinal projects, and it repeats at a coarser level: the entire event, meaning every instrument assigned to it, can be completed multiple times as a unit. This is the right fit when what recurs is the visit itself, not one form within it — unscheduled follow-up visits, repeated dialysis sessions, or any encounter type where the whole bundle of forms (vitals, notes, labs) needs to be re-collected together each time it happens, and the number of times isn’t fixed by the study’s Events schedule.

An event is configured as repeating (or not) on the same “Define My Events” setup screen used to build the event schedule, via the “Repeatable” checkbox next to that event. A project can mix both mechanisms: some events non-repeating with one repeating instrument inside them, other events repeating in full — but for a single event, REDCap makes you pick one shape or the other, not both: an event that repeats in full does not also support marking one of its own instruments as independently repeating beyond that.

Choosing between them

The practical test is: what’s the unit that recurs? If it’s one form’s worth of data inside an otherwise-fixed visit structure, repeat the instrument. If it’s the entire visit — every form tied to that encounter — repeat the event. Getting this backwards produces one of two awkward outcomes: forcing an entire event to repeat when only one form actually needed to (bloating every other instrument on that event with unused, always-instance-1 duplicates), or leaving an event non-repeating and trying to cram a genuinely recurring visit into a single instrument’s repeat instances, which loses the ability to track other forms per-visit.

How repeating data appears in exports

This is where the choice has real downstream consequences. Both the REDCap API and the browser-based data-export tool add two extra identifying columns to any export that includes repeating data: redcap_repeat_instrument and redcap_repeat_instance. For a row belonging to a repeating instrument, redcap_repeat_instrument holds that instrument’s name and redcap_repeat_instance holds the instance number. For a row belonging to a repeating event, redcap_repeat_instrument is left blank and only redcap_repeat_instance is populated, identifying which occurrence of the event it is. Rows from non-repeating instruments and events leave both columns blank. In a longitudinal project, a third column, redcap_event_name, is present regardless of repeating status and identifies which event a row belongs to.

The result is a genuinely long dataset rather than one row per record: a record with four adverse-event instances and one baseline visit doesn’t export as one wide row, it exports as several rows sharing the same record_id, distinguished by these repeat columns. Any script or wrapper library reading the export (see the REDCap API guide for token setup and export mechanics) needs to filter or group on redcap_repeat_instrument/redcap_repeat_instance explicitly — treating the export as one-row-per-record silently drops or duplicates data the moment any repeating instrument or event is in the project.

Analysis-side consequences

Because repeating data exports long, the reshape into an analysis-ready dataset is a real, separate step, not something that happens automatically:

• Reshaping to wide. If an analysis needs “number of adverse events” or “worst lab value across all instances” as a single column per record, that’s an aggregation the analyst has to build — count instances, take a max/min, or pivot named instances into columns — after export, not something REDCap computes for you inside the project.
• Referencing another instance from branching logic or a calculation. Fields inside a repeating instrument can reference values from a different instance of the same instrument (or from a non-repeating instrument) using REDCap’s instance-referencing bracket syntax rather than the plain [field_name] form used elsewhere — see the field-reference syntax covered in the branching logic guide and the calculated fields guide, both of which apply inside a repeating instrument with this extra instance-addressing layer on top.
• Custom instance labels. Because instances are numbered by default, a repeating instrument with many instances (e.g. a medication log) is hard to scan on the data-entry page unless a custom label — typically a piped value from a field on that same instance, like the drug name — is configured so each instance shows something more useful than “Instance 3” in the record’s repeating-instruments grid.
• Instance-level audit trail. REDCap’s logging records edits at the level of the specific instance that changed, not just the instrument or record — relevant when a project needs to show which occurrence of a repeating form was added or amended and when, the same audit granularity referenced for 21 CFR Part 11 electronic-records purposes on the 21 CFR Part 11 dictionary term.

A worked (illustrative) example

This is an illustrative composite, not a real study or institution. A trial coordinator sets up a Concomitant Medications form as a repeating instrument on a non-repeating Baseline event: each time a participant reports a new medication, the coordinator adds another instance, capturing drug name, dose, and start date on that instance. Separately, the same project has an Unscheduled Visit event marked as a repeating event, because an unplanned clinic visit can happen any number of times and each one needs its own vitals, notes, and adverse-event forms collected together. At export, the medications data comes back as multiple rows per participant identified by redcap_repeat_instrument = medications and an incrementing redcap_repeat_instance, while the unscheduled-visit data comes back as multiple rows per participant identified by a blank redcap_repeat_instrument, an incrementing redcap_repeat_instance, and redcap_event_name set to the unscheduled-visit event. The analyst reshapes each separately before merging into the analysis dataset.

Frequently asked questions

Can an instrument repeat inside a repeating event?

No — an event is repeating as a whole, or one of its instruments is independently repeating; REDCap doesn’t support layering both mechanisms on the same event at once. If a form inside a repeating event genuinely needs its own separate, differently-numbered repeat count from the rest of the event, that’s a sign the data model needs restructuring, not a configuration to force.

Do repeating instruments and repeating events require a longitudinal project?

Repeating instruments work in both classic and longitudinal projects. Repeating events require a longitudinal project, since only a longitudinal project has events to begin with.

How do I limit how many instances a user can add?

REDCap does not enforce a maximum instance count by default; a project team that needs a soft cap typically handles it with instructions on the instrument itself or a validation check downstream, not a built-in setting.

Does turning on repeating for an instrument that already has data lose anything?

Existing data on that instrument becomes instance 1; no data is deleted by enabling repeating. Turning it back off afterward, if the instrument now has more than one instance, is where data loss risk actually shows up, since REDCap has to decide what happens to instances beyond the first — treat that as a one-way door in practice and confirm behavior in a test project first.

Does the REDCap API return repeating data the same way as the browser export tool?

Yes — both add the same redcap_repeat_instrument/redcap_repeat_instance columns (and redcap_event_name for longitudinal projects), since both read from the same underlying data-export mechanism described in the REDCap API guide.