Billing

Last updated: Oct 26, 2026

The billing model uses the monthly activity of the authors. It uses the changes to the source code in the repositories that you registered on the platform.

The billing starts on the first business day of each month, when Fluid Attacks generates the author list of the previous month. Fluid Attacks examines this list manually to remove duplicate authors. There can be duplicates because an author can use other accounts for some commits, in addition to the primary email or account. Then, Fluid Attacks uses this clean list to calculate the billing of the organization for the month.

Fluid Attacks bills commits by the date of their merge into the configured branch on the platform. It does not use their creation date. Thus, the code analysis starts from that moment.

Because of this, the billing can include authors who did not make commits during the billed month. This can occur when developers make changes in branches before the final version (pre-release). Then, they integrate these commits into the active branch on the platform. The date when Fluid Attacks sees a commit can be different from its original authorship date.

You can register a repository on more than one branch (multi-branch support). Then, Fluid Attacks bills each registered branch independently for the month in which it sees the merged commits. Thus, if an author makes changes that go to different branches in different months, Fluid Attacks can bill that author two times.

Author identification

This process gets all the authors (persons or bots) who changed the source code (additions, modifications, deletions). Fluid Attacks counts only the changes that it sees as merged on a date in the previous month. To do this, Fluid Attacks uses the Git history of each repository. It uses only the branch that you configured on the platform. The diagram below shows the procedure to generate the report of authors. The subsections below give the details of author identification in simple words.

Preliminary considerations

Author identification uses these items:

• Git, a distributed version control system. Git gives the "change history" of code projects. With Git, you can:
  • Save versions of the work of a developer with "commits".
  • Record each change, who made it, and when.
  • Create branches to work on new features independently, and then merge them into the primary project.
• The synchronization of the commit history from a Git repository with the Snowflake database of Fluid Attacks.
• Snowflake, a single Fluid Attacks database that keeps the complete and permanent history of all the commits. It is the single source of truth for all the analysis.
• DynamoDB, a component that keeps the hash of the last processed commit. This hash tells Fluid Attacks where to continue in the next run. Thus, slow and expensive queries to Snowflake are not necessary.
• The unique commit identifier, which the system uses to see if a commit is already in Snowflake. The system uses a combination of group name, repository nickname, and commit hash.

Process

The process has these steps:

1. Cloning: The system clones the latest version of the Git repository to make sure that it has the most recent history.
2. Checking of the starting point: The system must know the point from which it records new commits:
   (a) The system queries DynamoDB to get the hash of the "commit of reference" (the last commit in Snowflake).
   (b) The system searches for the hash in the history of the new clone. Thus, the system makes sure that nobody changed the history.
3. Scenario 1: The commit of reference exists: This is the most common and the fastest scenario:
   (a) The system finds the commit of reference in the history.
   (b) The system iterates through the Git history from the commit of reference. Then, it inserts only the new commits into Snowflake.
   (c) DynamoDB keeps the hash of each commit that the system inserts and updates the commit of reference.
4. Scenario 2: The commit of reference does not exist: This scenario occurs if someone rewrote the Git history. The DynamoDB "marker" is then not correct. In this scenario:
   (a) The process does not find the commit of reference. This shows that the integrity of the history changed.
   (b) To prevent the loss or duplication of information, the system starts a full synchronization:
   (i) It iterates through all of the Git history, from the first commit to the last. For each commit, it checks Snowflake (with group name, repository nickname, and commit hash) to see if the commit is already there.
   (ii) If a commit is not in Snowflake, the system inserts it. This method is slower than the method in Scenario 1. But when someone changes the Git history, this method continues to keep the data correct.
5. Author count: To bill a client, Fluid Attacks validates all the commits that it inserted into Snowflake during the month. Fluid Attacks counts each author of these commits only one time. The total gives the amount that the client must pay.

Billing report generation

In this phase, the process removes duplicate commits and puts together the information from all the repositories of the organization. These lists include the names of the authors, the groups that they contributed to, the commit IDs, and the repository names. The lists show an example for each author. The process does not include the authors who contribute only to files outside the scope of testing.

Then, you can examine these reports on the platform, in the Billing section of your organization and in the Authors section of your groups.

Billing section in the organization

Authors section in a group

Use the filters to examine the authors easily.