Turn on the production loop for AWS

Connect an AWS environment so alarms start investigations, recorded deploys receive verification checks, and scheduled scans and weekly reports run. Follow the steps in order, then use the revocation procedure when access should stop.

Before you start#

You need an administrator of the GitHub organization and someone authorized to apply IAM and EventBridge changes in AWS. Create an environment and link its repositories first.

Have the alarm intake binding identifier, HTTPS endpoint, credential and approved alarm ARNs provisioned for this organization, environment, AWS connection and region. The installer consumes these inputs; it does not provision them. If they are unavailable, stop before applying the forwarding template.

For deploy verification metrics, the read role also needs an approved cloudwatch:GetMetricData grant for the selected region. The default read-role template does not grant this optional access.

1. Apply read access and alarm forwarding#

1. Open Settings → Connections → AWS and start connecting an AWS account.
2. Select the account and installation region.
3. In the installation methods, select Read access and alarm forwarding.
4. Choose CloudFormation or Terraform under Template format.
5. Review the generated files and apply them through your authorized deployment process.

For CloudFormation, save the template and upload it when creating a stack in the selected region. Review the destination URL before supplying its credential. Acknowledge named IAM resources.

For Terraform, save proofline.tf and proofline-alarms.tf.json in the same root and apply them together. Supply the intake inputs through your deployment process. Keep the credential out of committed files and command history. Terraform state contains it, so restrict state access.

Use one stack or root to own the account-wide read role. Import an existing role before adopting the generated files. Install forwarding in each approved alarm region. The rule forwards only the listed alarms' transitions to ALARM; it leaves existing alarm actions and paging destinations unchanged.

The console does not confirm an apply. Return to AWS connection setup for the read-access check in the next step.

2. Connect the account and confirm inventory#

1. Return to the AWS connection and select Check connection, or I applied it while Proofline is checking.
2. Confirm that Setup shows connected access. Use Diagnostics for the last check and any error.
3. Open the environment's Setup page and select Add under AWS accounts.
4. Select the connected account, choose its region and resource scope, then select Link account.
5. Open Overview and find the account under Inventory. Check Last collection, the resource types read under Coverage, and any collection gaps.

Use the repair action beside a collection gap when one appears. An absent Inventory section, Waiting for the first collection, Collection is off, or an overdue collection does not confirm current inventory. Resolve the setup or collection problem before continuing. A connected role alone does not establish usable inventory or complete infrastructure evidence.

Exercise an approved alarm after linking the account. Open the environment's Investigations tab and find the matching CloudWatch alarm entry. Open it to inspect its evidence and gaps (Investigate an environment). If no entry appears, check the forwarding stack, destination and provisioned alarm allowlist before continuing.

3. Configure deploy verification#

Confirm the environment's repository links and delivery configuration match its actual deployment path. A GitHub deployment must report success to a linked GitHub Environment. A workflow-only link supplies no GitHub deployment landing. AWS CodePipeline and Amplify need their configured delivery targets.

1. Open the environment's Setup page and find Deploy verification.
2. Select Add signal.
3. Set Provider to AWS CloudWatch.
4. Select the linked AWS account and region.
5. Enter the signal's name, namespace, metric name and exact dimensions. Add its unit when needed.
6. Set Statistic, Worse when, Tolerance (%) and Minimum change for that metric.
7. Select Save signals.

Leave No data means zero clear unless an absent value means zero for this counter. A metric that cannot be read leaves its check incomplete.

Reopen Setup to confirm the saved signals. After the next recorded deployment lands, open Deploys and select it. Checks shows the verification results; Signals shows the baseline and observed values. Checks compare configured signals with the hour before landing, at landing, 20 minutes, 1 hour and 1 day.

Saving signals does not start a verification or establish that a deployed revision is serving. Inspect each deploy's recorded gaps. Deployment protection has its own setup; configuring verification signals creates no gate.

4. Schedule scans with a credit ceiling#

Follow Schedule latent-risk scans to choose families, cadence, time zone and Credit ceiling per scan. On an empty Latent risks page, select Schedule scans; otherwise select New schedule.

Confirm the schedule appears on Latent risks. After its scheduled time, inspect the recent scan's outcome, examined families and evidence gaps. A scan stops before its next model request would exceed the ceiling. A funding refusal starts no scan; inspect usage and billing.

If you want new problems posted to Slack, set Existing-problems channel on Latent risks. This destination is separate from the weekly report channel.

5. Set the weekly report and destination#

1. Follow Set up Slack delivery to connect the workspace and save its delivery channel.
2. Select Send test message and confirm Test message sent. in the console, then check the channel.
3. Return to the environment's Setup page.
4. Under Weekly report, select Send a weekly report.

The checked box confirms the saved schedule. The reporting week is Monday to Sunday, UTC; there is no day or time picker. After the week ends, Weekly report lists the retained report and whether it was sent to Slack. Open it to inspect the week's results and Not established measures.

Without a connected channel, Proofline retains the report without posting its note. The Slack guide explains how to replace or disconnect the destination.

Revoke access#

Use this order to stop scheduled work, remove delivery destinations, disconnect AWS and remove its infrastructure grants. Check other environments before changing an organization-wide connection or channel.

1. Disable schedules. On Latent risks, open each schedule, clear Run this schedule, then select Save schedule. In Setup → Weekly report, clear Send a weekly report. A weekly note not yet sent is withdrawn.
2. Remove destinations. Select Stop posting under Existing-problems channel. For a full organization disconnect, open Settings → Connections → Slack, select Disconnect Slack, then confirm Disconnect. These channels serve the organization; keep a shared destination when another environment still uses it.
3. Disconnect the AWS account. In each linked environment's Setup → AWS accounts, open the account and select Unlink from this environment. Then follow Remove a connection: open the AWS connection's Settings and select Remove connection. Resolve any listed dependencies before confirming. Check the console's final state and retry cleanup if requested.
4. Remove the AWS resources. Delete the CloudFormation stack, or remove the Proofline Terraform module or generated resources from their owning root and apply the reviewed plan. Remove forwarding in every region where you installed it. Confirm the read role, forwarding rule, destination and delivery role are gone in AWS.

Disconnecting in Proofline does not delete your stack or change your Terraform state. Disable schedules first even when you intend to delete them. Deleting a scan schedule keeps recorded scans and existing problems.

Records after revocation#

Revocation does not erase recorded history. These retention periods continue after you disconnect:

Expiry often clears content while preserving its record and digest. Delete an organization explains erasure. Minimized audit evidence stays for 365 days after deletion; billing records stay for seven years, with longer retention possible for a hold. Deleted database rows remain recoverable in backups for 7 days.