Simple Email Service → Reputation Dashboard - Check the bounce rate and the complaint rate. If bounces or complaints get too high, AWS can shut down our ability to send email. This shuts down any study that uses email for authentication (which is a majority of studies).
Note that the metrics are based on the last 10000 emails, and we send something like 10 per day, so this metric changes very slowly.
To see individual bounces and complaints, go to https://groups.google.com/a/sagebase.org/g/bridge-bounce-notifications. Bounces are mostly fine. Complaints need to be looked at closely.
Simple Notification Service → Text Messaging (SMS) - Scroll down to Delivery Status Logs and look at SMS delivery since the last dev-ops meeting. Failures due to opted out are generally fine. Other failures should be looked at closely, especially if it’s widespread.

Redrive Exports

Whenever an export in either 2.0 or 3.0 fails due to a bug or server error, we need to redrive those exports. Our process is as follows:

At the start of each month, create a Jira for this month’s redrives. See
Jira Legacy
server System JIRA
serverId ba6fb084-9827-3160-8067-8ac7470f78b2
key BRIDGE-2794
for an example.
Over the course of the month, whenever Ops finds an upload that needs to be redriven, add it to the Jira (ideally with the appId and studyId, so we can validate if needed).
At the end of each month, create a text file with each upload ID, one ID per line, and upload it to S3 bucket org-sagebridge-backfill-prod in the Bridge-Prod AWS account.
Get written approval from the Director of Bridge (currently Erin Mounts). For tracking purposes, this is best done as a comment in the Jira.
Write the JSON message to the Bridge-Worker-Request-Prod SQS queue to kick off the redrive.

See Bridge Data Change Request Process for information on the formal redrive process.

TODO

Jira Legacy

Mobile Apps

under construction