Codemagic billed us for identical failed builds. Support confirms: no cap, no alerts, and the skip filter does nothing until a build succeeds.

[gil-silverlining]

If you are looking for help, please confirm the following...

• I confirm I have searched the Docs, Codemagic Sample Projects, and GitHub Discussions.
• I confirm the software versions on my local computer match the ones in CI environment (e.g. Xcode version, Gradle version). See here
• I confirm I am able to do a fresh clone of the repository and build the project on my local computer.

Which mobile framework are you using?

Other - please mention in your question

Steps to reproduce

see below

Expected results

see below

Actual results

A push trigger on a new Android workflow, plus a one-line Gradle error, meant every git push for eight days ran a Mac mini M2 build that failed at the same line. Same error every time. All billed. I found out from the charge email for $180.

I asked for a refund. Support's answer, quoted:

You're correct that when changeset is first configured, a build needs to complete successfully before subsequent builds can be skipped based on the changeset condition. However, the builds during this period were triggered by the configured push trigger and consumed build machine time before failing due to the Gradle error in the project. Failed builds are still counted as billable usage unless the failure is caused by a Codemagic service error.

So, confirmed by Codemagic:

• when: changeset is the cost control the docs point you to, and it does nothing on a workflow that has never gone green. Which is exactly when a workflow is most likely to loop.
• A workflow can fail on the same error hundreds of times and the platform bills every run without pausing, warning, or notifying anyone. Nothing is sent on failure unless you wire it up yourself.
• There is no spend cap on pay-as-you-go.
• The only spend notification that exists fires at $333. It is not on the billing page or in the docs. Support confirmed it after I asked several times. Why $333?

Yes, the trigger was ours. That is what guard rails are for. Every other metered service I pay for has a cap or a threshold alert, and most pause a job that fails identically N times in a row. Codemagic has none of those, and its position is that the meter ran, so the money is theirs.

Asks:

1. Refund the days of identical failures. Nobody disputes those produced nothing.
2. A spend cap. Usage alerts at the free-tier boundary and at thresholds users set. Failure notifications on by default. And either make changeset skipping work on a red workflow, or put a warning in the docs and the UI where the filter is configured.

Build id (optional)

No response

[icarusdust]

Hi @gil-silverlining, I understand the situation you're describing and how frustrating it can be to discover unexpected build usage. Thanks for taking the time to share the details and your suggestions on how we could improve the experience.

There are a few separate aspects here, and I’d like to provide some context on them.

Regarding notifications, since notification preferences depend on how each workflow and team operates, they are inherently dependent on the user's workflow, team, and operating model, so teams can explicitly choose which events they want to be notified about. The notification functionality is available for exactly this purpose, giving users control over whether and how they receive notifications. These notifications are configurable.

I also want to clarify the skip condition: when condition can be used to prevent a build from further building based on the commit message, for example:

    when: 
        condition: not event.pull_request.title == "skip_building"

Please note that it's not changeset but condition. This will start the build but exit without further building. If you need an instant skip, you can add [skip ci] or [ci skip] in commit messages, and the builds will skip entirely.

On the billing side, the Free plan includes 500 build minutes per month. Reaching that limit does not by itself result in automatic charges, builds stop until billing is explicitly enabled on the account by the account owner. Once billing is enabled, build usage is visible and trackable from the billing page, including the free minutes and any additional usage.

That said, I appreciate the feedback around the points you raised. Some of these, such as additional usage thresholds or billing caps, are useful product considerations that we can evaluate with the product team. I’ll share your feedback with them for further consideration.

Thanks again for the constructive feedback.

[gil-silverlining]

Nowhere in your settings section is a notification availble for setting notification type and frequency. Not for failures, not for spend.

I was required to put a card on file in order to use the service -- so your statement is false. You force us to enable billing from the start.

The fact is there is zero safeguards and no notifications on failing builds which would have prevented this whole thing from happening. These aren't "useful considerations" .. these are highlighting core SaaS product requirements that you are lacking that has resulted in a single person (not a corporation) losing a tremendous amount of money because of it. I appreciate you stating 500 free minutes but to access this billing needed to be enabled! I will be seeking remedy from my bank I am sorry the way it has been handled has not been satisfactory and many other people should be warned about the pitfalls of using your product.

In this day and age, no spending limits, no spending notifications, is truly a major deficiency.

[icarusdust]

I was required to put a card on file in order to use the service

I appreciate you stating 500 free minutes but to access this billing needed to be enabled!

I’d like to clarify this point, as this is not how the product works. When you sign up and create a Personal account, billing does not need to be enabled to access or use those minutes. This can also be verified from the Billing page.

Regarding notifications for failing builds, we have built-in notification integrations including email notifications and Slack notifications, which can be configured to notify users when a workflow fails.