Check your install

1. What should be there

• Workers & Pages: your site, under the name you chose (afterwrd unless you changed it). Nothing called afterwrd-installer-…: the installer removes itself once your site is running. Each group you start later appears here as a Worker of its own.
• D1: one database with your site's name (and later one per group).
• Nothing else you didn't make yourself. afterwrd doesn't use scheduled (cron) triggers, custom domains, or any other Cloudflare product.

2. What the audit log should show

Open the audit log and look at the minutes around when you installed. First, Cloudflare's Deploy page making the installer (marked Dashboard). Then what the installer did with the permission you allowed, each marked OAuth in the Actor Context column, in this order:

1. Create Worker Assets Upload Session
2. Upload Worker Assets (a few times)
3. Create D1 Database
4. Upload Worker
5. Update Worker Script Subdomain
6. Delete Worker (the installer removing itself)

An update from your site's Update page leaves the same kind of trail, without the last three, and a group being started leaves its own (with the group's name). Anything else marked OAuth around then, such as changes to other Workers, DNS, members or API tokens, wasn't afterwrd. If there's a long list of page views, filter with Action Type is not view.

Cloudflare's log says an app you allowed did these things, but not which app. That's why the order and the names above matter.

3. Take the permission back

afterwrd doesn't need to keep access to your account: every update asks again. Under Connected applications, revoke afterwrd if you like. Revoking stops it being given new access; access it was already given still lasts out its hour.

Or ask a friend to check it

If a friend has an afterwrd site, theirs can do the careful part for you. On your new site, go to Update and press Ask a friend to check my site: it writes a message for you to send them, however you usually would. They paste it into their own Friends page and send you back a link. You open it and allow read-only access when Cloudflare asks. Their site then downloads your site's code from Cloudflare, compares every file with the published release, checks how it's set up, and reads your account's log for anything afterwrd doesn't do. You both see what it found. It can't change anything, and the access isn't kept.

The request goes by message rather than between the two sites on purpose: if your site had been tampered with, it couldn't fake the check.

If something looks wrong

• Don't sign in to the new site or import anything into it yet.
• Revoke afterwrd under Connected applications, and check your Cloudflare password and two-factor sign-in.
• Delete the site's Worker and its database, and anything else you don't recognise.
• Please tell us, privately: report a security problem.

For technical people: compare the code

The code running on your site can be downloaded with a read-only Cloudflare API token and compared, file by file, with the published release or with your own rebuild of it (see Check it yourself). The code carries the fingerprint of every other file the site serves and refuses any that doesn't match, so matching code covers those files. It doesn't cover how the Worker is set up in Cloudflare (what it's connected to, where its logs go); a friend's check, above, looks at that too. Make a token with Workers Scripts: Read for the account, then, in a copy of the repository:

read -rs CF_TOKEN && export CF_TOKEN   # paste the token; nothing shows
node worker/scripts/check-site.mjs afterwrd

It only reads, and prints whether each file matches. Delete the token afterwards.