Keep GitHub audit streaming continuous across maintenance

Name the four evidence clocks

Audit-stream maintenance succeeds when the organization can explain what was delivered, what was preserved and what remains missing. A receiver returning to a healthy state is only one part of that result. Separate native GitHub history, the paused-stream buffer, destination acceptance and the organization's retained archive before choosing a maintenance window.

GitHub Enterprise Cloud documents native audit-event history of 180 days and Git-event history of seven days. The default displayed period is another view setting, not a different retention guarantee. Identify the event class first; a general statement that GitHub keeps audit logs does not describe every relevant record population. ^[2]

The paused stream and receiving service have separate limits. GitHub documents a seven-day pause buffer and, for its Datadog integration guidance, an eighteen-hour accepted event age. Those constraints should not be treated as equivalent product-retention features. A destination can impose a tighter delivery condition than the source's buffer suggests. ^[1]

The chart uses separate panels for native-history days and delivery-window hours. Its 168-hour value is only the arithmetic conversion of seven days for the delivery comparison. It contains no measured reliability or recovery speed. Do not infer that an organization can safely pause for the longest bar without considering every relevant boundary.

Start the change record by naming which events matter, which receiver accepts them and where the durable copy lives. Include the last confirmed delivery, the proposed pause and a decision point for abandoning maintenance if recovery takes longer than planned. This is a recommended planning structure, not a claim that any enterprise stream was inspected.

The archive is the organization's own responsibility. Native retention and successful delivery do not establish how long the downstream copy will remain readable, whether its parser preserved the event or whether an investigator can access it. Keep those questions visible instead of assigning every continuity problem to the source platform.

Source. GitHub Enterprise Cloud documentation, reviewed September 2, 2026. ^[1][2]

Method. Direct limits, with seven days multiplied by 24 for the pause-buffer row. Separate scopes and units. Not an availability or replay guarantee.

Accessible table and figure data

Figure 1 accessible table

Constraint	Days	Hours
Native audit history	180	Not applicable
Native Git history	7	Not applicable
GitHub pause buffer	Not applicable	168
Datadog age per GitHub guidance	Not applicable	18

Figure 1 accessible table

Constraint	Days	Hours
Native audit history	180	Not applicable
Native Git history	7	Not applicable
GitHub pause buffer	Not applicable	168
Datadog age per GitHub guidance	Not applicable	18

Download imageDownload table CSV

Define what the stream actually includes

GitHub describes enterprise audit streaming as including activity across the enterprise's organizations, starting from enablement, with at-least-once delivery. The delivery guarantee means consumers must be prepared for repeated material. It does not mean that every historical record can be requested again through the streaming configuration. ^[1]

Enterprise access is also scoped. GitHub's access documentation identifies enterprise-owner access for this audit view. Establish which authorized identity can inspect the source, retrieve evidence and administer the stream. An operator's ability to view one organization's activity should not be assumed to cover the entire enterprise collection. ^[6]

Keep an event-class inventory beside the stream configuration. Include the activity classes the investigation expects, any relevant optional collection settings and the receiver's parsing assumptions. A record that reaches storage but is ignored by a normalization rule can disappear from the analyst's view without being absent from the raw delivery.

Do not use the browser search as a universal stream inventory. GitHub documents that the audit-log user interface does not search Git events and uses structured search qualifiers rather than arbitrary full-text matching. A query result from that interface therefore cannot prove that the stream's entire event population was recovered. ^[5]

A useful hypothetical maintenance case includes both administrative activity and Git activity. If only the administrative class is checked after resumption, the team has demonstrated a narrower result than full continuity. The test receipt should say which classes were observed, which were expected but unavailable and which were outside the exercise.

The same distinction applies to API request logging options and preview capabilities. Review the exact enabled features for the enterprise instead of assuming a diagram of all possible events matches the actual source. This article does not require preview multi-endpoint streaming as a continuity control, and it does not generalize Enterprise Cloud behavior to Enterprise Server.

Choose a maintenance boundary before pausing

GitHub's pause behavior is bounded: a longer pause resumes from the retained recent week, and a pause of at least three weeks starts a new stream from the current point. Preserve that distinction between a bounded backlog and a fresh start. Neither is a promise to reconstruct the whole maintenance interval. ^[1]

Choose a maintenance duration against the tightest relevant condition, including receiver acceptance. The eighteen-hour Datadog value here is attributed specifically to GitHub's integration guidance; a separate Datadog API page was not verified for this article. It must not be generalized to every Datadog ingestion path. ^[1]

Before pausing, preserve the stream configuration and the last confirmed receipt boundary. Record how confirmation was obtained: a raw object, receiver acknowledgement, normalized event or a combination. These observations have different meanings, and the change lead should know which one supports the proposed recovery window.

Define an abort or alternate-response decision in advance. If the receiver cannot be restored within the approved boundary, identify who chooses the next authorized action and which event populations may be lost. A deadline that nobody owns is not an operational control. Avoid improvising an unreviewed destination or broad credential change during the outage.

The before-and-after framework describes a planning improvement, not measured recovery performance. Its after state includes a bounded pause, a receipt boundary, duplicate-aware processing and an explicit gap output. The purpose is to make an unsuccessful or partial recovery explainable, not to guarantee that every maintenance event ends without missing evidence.

Keep the source buffer's clock separate from the team's working hours. A weekend or shift handoff does not suspend the service's documented limits. The receipt should include absolute timestamps and an owner available to act at the decision point, rather than a vague promise to resume when the maintenance team returns.

Source. Original continuity framework informed by GitHub stream, API and export documentation. ^[1][3][4]

Method. Conceptual comparison, not measured recovery performance.

Accessible table and figure data

Figure 2 accessible table

Boundary	Before	After
Pause	No defined evidence boundary	Last confirmed receipt and deadline
Resume	Healthy receiver assumed sufficient	Raw arrival, parsing and archive checked
Reconciliation	Missing classes hidden by status	Recovered, duplicate and unresolved separated

Figure 2 accessible table

Boundary	Before	After
Pause	No defined evidence boundary	Last confirmed receipt and deadline
Resume	Healthy receiver assumed sufficient	Raw arrival, parsing and archive checked
Reconciliation	Missing classes hidden by status	Recovered, duplicate and unresolved separated

Download imageDownload table CSV

Treat health checks as one signal

GitHub documents a daily streaming health check and guidance to correct a misconfigured destination within six days. These are source-side operational signals. They do not prove that a downstream parser, archive or investigator query has processed the intended event population. ^[1]

Build a layered observation set for maintenance. Confirm that new raw material arrives, that the receiver accepts it, that parsing succeeds and that the resulting events reach the intended storage or search destination. This is an original recommended review structure, not a GitHub-provided end-to-end service-level agreement.

A healthy source check can coexist with a local transformation failure. For example, a hypothetical receiver stores compressed payloads successfully while a schema change causes normalization to reject a class of events. The continuity result is partial: delivery succeeded, but analyst visibility did not. The correct response is to preserve raw input and repair the affected processing boundary.

Conversely, an empty query may reflect a genuinely quiet period rather than a failed stream. Use an authorized known activity when necessary to test the relevant class, and state what was observed. Do not invent expected event volumes or label every low-volume interval as an outage.

Assign separate owners where needed. The enterprise administrator may own source configuration, a platform team may own the receiver and a security team may own the normalized schema. A maintenance ticket should connect those responsibilities rather than leaving the final success decision to whichever dashboard turns green first.

The observation set should retain exceptions. A failed parser batch, delayed object or missing event class needs a reference and next action even if the overall service resumes. A summarized healthy status is useful for operations, but it should not erase evidence about the period that investigators may later need to reconstruct.

Keep raw and normalized receipts

At-least-once delivery makes duplicate handling a design requirement. Preserve raw delivery provenance separately from normalized event identity. An object receipt can establish that bytes arrived through a particular path; it does not automatically establish that each logical event appears only once in the analyst's dataset.

Do not deduplicate solely by actor and timestamp. Two legitimate actions can share both values, and a repeated delivery may have different transport metadata. Inspect the actual event schema and define identity rules appropriate to the event class. A universal stable deduplication field was not verified for every GitHub event in this research.

A recommended receipt stores the source reference, arrival time, parsing version, processing outcome and relationship to normalized records. Keep enough lineage to reprocess a corrected parser without losing the distinction between original delivery and later interpretation. Sensitive payloads should remain in a controlled archive rather than a general maintenance chat.

Define what a repeated logical event should do downstream. It may be ignored for a count, retained as a duplicate receipt, or associated with an existing investigation. The rule should be explicit and reversible enough to examine a suspected false merge. Silent overwriting can make a clean-looking dataset difficult to audit.

Test the rule with clearly synthetic cases: identical repeated input, two distinct operations sharing actor and timestamp, and an event with a missing optional identifier. These are proposed acceptance cases, not executed tests or fabricated duplicate rates. Preserve an exception route when the schema does not support a confident identity decision.

Raw retention also supports correction after maintenance. If a parsing defect is discovered later, the team can work from the original material rather than asking the source to replay beyond its supported window. That benefit depends on the archive actually being readable and retained under the organization's policy; it is not supplied by the stream setting alone.

Define a quarantine path for records that cannot be normalized confidently. Retain their raw references and a reason for the exception rather than discarding them or forcing them into an incomplete schema. After a parser correction, reprocessing should preserve the original arrival context and identify the later processing version. This makes an uncertain event visible to an investigator without pretending that the downstream data model already understands it.

Recover only what the API can return

The enterprise audit API has its own access, pagination and rate-limit requirements. GitHub documents UTC epoch-millisecond timestamps and a limit of 1,750 queries per hour for the user and IP combination. Plan retrieval around the supported interface rather than repeatedly issuing broad requests until a gap appears filled. ^[3]

Exports have different boundaries. GitHub documents a compressed-size or processing-time limit, and Git-event exports exclude Git operations initiated through browser or API activity such as a web merge. A native export should therefore not be represented as a guaranteed replacement for every streamed event class. ^[4]

For a recovery attempt, define the missing population first. Identify event classes, time interval and source route. Then document which supported API or export can retrieve that population and which parts remain unavailable. A file containing some relevant records is useful evidence, but it is not automatically a complete backfill.

Record pagination progress and failures. If a request is interrupted or a segment reaches a limit, retain its status and resume through a reviewed procedure. Reconcile overlapping segments using the established event-identity policy. Do not remove repeated-looking rows by visual inspection merely to produce a tidy final count.

Keep recovery access scoped to the investigation. An enterprise owner may need to perform retrieval or authorize the appropriate workflow, but that does not justify distributing broad administrative credentials to every analyst. Preserve a controlled evidence handoff and enough metadata for review without exposing tokens or unnecessary account details.

The final recovery report should distinguish recovered, already present, unresolved and unsupported populations. This classification is more useful than a single backfill-complete checkbox. If a class cannot be recovered through the available interface, state the reason and retain the loss as part of the maintenance outcome.

Keep stream trust separate from Actions

S3 audit-stream OIDC trust is not GitHub Actions deployment trust. GitHub's streaming documentation specifies the audit-log issuer at oidc-configuration.audit-log.githubusercontent.com and an enterprise-specific subject using the enterprise URL. These values should not be replaced with familiar Actions trust values. The documented data-residency exception also needs review before selecting this option. ^[1]

Treat the receiver trust review as a separate change from application deployment automation. Identify who may configure the stream, which enterprise can assume the destination role and which destination resources that role can use. A working Actions integration is not evidence that the audit-stream trust is correct.

Preserve exact identifiers in the restricted implementation record, including case-sensitive subject requirements described by the provider. The public guide need not expose a real enterprise name or bucket. A reviewer should verify the actual values against current documentation before any deployment, rather than copying an example with a plausible-looking substitution.

No credential, role or destination was created for this article. The recommendation is to review the trust boundary during planning and again after a relevant enterprise or destination change. Keep authentication success separate from event continuity: a role can be assumable while the receiver still rejects, misroutes or misparses the delivered evidence.

Where an existing integration is being replaced, record the old and new trust paths and the intended overlap or cutover behavior. Do not delete the only useful evidence receipt before the replacement path is verified. Any change in archival ownership should also preserve the authorized investigation access needed after the maintenance team finishes.

Close maintenance with reconciliation

Close the change only after reconciling the planned receipt boundary with the resumed stream and the available recovery routes. State which classes resumed, which repeated records were handled under the documented identity rule and which intervals remain uncertain. Healthy current delivery is evidence about the present, not automatic proof of uninterrupted history.

Retain a concise maintenance record with configuration, pause and resume times, receiver constraints, raw receipt references, parser version, retrieval attempts and unresolved populations. The record should be understandable to an investigator who encounters the gap months later, without relying on the memory of the operator who performed the change.

Finally, make the next maintenance plan more specific. A receiver acceptance limit, missing event class or weak deduplication rule should become an owned correction. Do not turn the result into a universal exactly-once or full-replay claim. The practical standard is continuity that can be demonstrated where it exists and described honestly where it does not.