How to publish a Simply Static site on Netlify through GitHub without burning all your credits

If you deploy Simply Static Pro to GitHub and let Netlify build on every push, one export can trigger dozens of builds and eat a month of build minutes in an afternoon. The fix is one small file in your repository that tells Netlify to ignore pushes and only build when Simply Static’s webhook fires. 

This guide walks through the whole setup, from the Simply Static settings to the Netlify options that quietly undo the fix if you leave them at their defaults.

Why one export turns into dozens of builds

Simply Static Pro’s GitHub delivery method pushes your exported files into a repository, then calls a Netlify build hook to publish them. That sounds like one deploy, but it usually isn’t.

Simply Static commits through the GitHub Contents API, which writes files one at a time. Each commit is a separate push event, and if your Netlify site is set to deploy on every push by default. Each of those pushes triggers a build. Then the build hook fires at the end and starts one more. A 130-file export can produce well over a hundred builds.

This is what running out looks like. Every one of these is a separate commit from a single export with the default settings:

The way to prevent this is to make the build hook the only trigger. Netlify can be told to skip any build that was started by a push, and to go ahead only when the build hook started it.

One thing to avoid: do not use Netlify’s “Stop builds” control for this. It is a global kill switch that blocks the build hook as well, so nothing deploys at all. Leave the site on Active builds and let the ignore command do the filtering.

What you need before you start

• Simply Static Pro, since the free version doesn’t include GitHub delivery.
• A GitHub repository for the exported site. A private repository is fine, and usually the right choice, since the export contains your whole site.
• A Netlify site connected to that repository.
• A build hook URL from Netlify, which you will paste into Simply Static.

Creating the build hook

In Netlify, open your project and go to Project configuration → Build & deploy → Build hooks, then click Add build hook. Give it a name you’ll recognise later like “Simply Static export”. Set Branch to build to the branch Simply Static pushes to.

Netlify generates the URL when you save. Copy it then, because it’s the value you paste into Simply Static’s Webhook URL field in the next step.

Part 1: Simply Static settings

In WordPress, go to Simply Static → Settings → Deploy and set the delivery method to GitHub. You will need to connect your GitHub account and then choose:

The Webhook URL field is the important one. Simply Static calls it, after all the files have been pushed, and that single call is what you want Netlify to act on.

Two other fields on that screen are worth knowing about. Visibility should be Private unless you have a reason otherwise, since the repository holds a full copy of your site. Batch size controls how many files Simply Static processes at a time; leave it at the default and only lower it if exports start failing partway through.

The Single Push settings

Simply Static’s Single Push feature regenerates a handful of pages rather than the whole site, which cuts export time dramatically. Since file count drives how long the GitHub push takes, it is the cheapest speed win available.

The setting that matters most here is Use Auto Push. Leave it off unless you genuinely want a deploy every time someone saves a post. With it off, an export, and therefore a deploy, only happens when you ask for one.

Below it, Pages to update and Taxonomy archives decide what a single push actually regenerates. The three toggles underneath (archives, pagination and XML sitemap) each add files to every push. If your build times are the problem rather than your build count, turning off pagination and archive updates is where the savings are.

One more setting lives in Simply Static’s general settings rather than here: clear directory before export. Turn it off. If it is on, Simply Static can wipe the repository contents before pushing, and that includes the configuration file you are about to add.

Part 2: Add a netlify.toml file to the repository

This one file does the work: it tells Netlify there is nothing to build, where the finished files live, and when to skip a build entirely.

It has to sit at the root of the repository, on the branch Simply Static pushes to. You don’t need a local clone, since GitHub’s web editor is enough:

1. Open the repository on GitHub and check the branch selector shows your deploy branch (main).

2. Click Add file → Create new file.

3. Type netlify.toml as the filename, with no folder prefix, so it lands at the root.

4. Paste in:

[build]
  command = ""
  publish = "."
  ignore = "if [ -n \"$INCOMING_HOOK_TITLE\" ]; then exit 1; else exit 0; fi"

5. Scroll down, keep Commit directly to the main branch, and commit.

If you set a folder path in Simply Static instead of pushing to the root, change publish to match that folder, for example publish = "site".

What each line does:

• command = "": there is no build step. Simply Static has already produced finished HTML, so Netlify’s only job is to publish it.
• publish = ".": serve the repository root, which is where the export lands.
• ignore = "...": this runs before every build and decides whether it goes ahead. Netlify sets the INCOMING_HOOK_TITLE variable only when a build hook started the build, so:
  • Started by a push: the variable is empty, the command exits 0, and Netlify skips the build. Skipped builds don’t consume build minutes.
  • Started by the build hook: the variable is set, the command exits 1, and the build proceeds. That is your one deploy per export.

The exit codes look backwards, and it catches people out. In Netlify’s ignore command, exit 0 means “nothing changed, skip this” and exit 1 means “go ahead and build”.

If you would rather work from a clone, the equivalent is:

git clone https://github.com/your-username/your-static-repo.git
cd your-static-repo
# create netlify.toml with the content above, then:
git add netlify.toml
git commit -m "Build only on the Simply Static hook, not on push"
git push

Committed and viewed on GitHub, the finished file looks like this:

The file in that screenshot carries more than the four lines above: a [functions] block and a long set of security headers. That is because netlify.toml is where all of Netlify’s per-site configuration lives. Yours only needs the [build] block to make this work; everything else is optional and can be added later.

Part 3: Netlify settings

Everything below is in the Netlify dashboard, under Project configuration in your project’s sidebar. If your dashboard still says “Site configuration” and “Sites” rather than “Project configuration” and “Projects”, it’s the same set of screens under the older naming.

Build settings: no build command, and leave the status on Active builds

Project configuration → Build & deploy → Build settings

netlify.toml already sets the build command and publish directory, and the file wins over the UI, but it is worth making sure the two agree so nothing confuses you later:

Build status sits at the bottom of the same panel, and it needs to stay on Active builds. If you stopped builds earlier while trying to control the flood, turn them back on. With builds stopped, the build hook does nothing and your site never updates. The ignore command is what filters the pushes now.

One field to leave alone: Functions directory. If your site uses Netlify Functions (a contact form handler, for example), this stays pointed at netlify/functions and the functions are deployed from your repository along with the static files.

Deploy only the production branch

Project configuration → Build & deploy → Branches and deploy contexts

• Production branch: the branch Simply Static pushes to, usually main
• Branch deploys: None (deploy only the production branch)
• Deploy Previews: None

Deploy previews are meant for pull requests, which a static export repository never has. Turning them off removes one more way a build can start unexpectedly.

Keep an eye on usage

Build minutes are counted per team, not per project, so a second site on the same team shares the same allowance. Open Builds → Build stats from the team sidebar, or Usage & billing, to see the minutes used against your current cycle. Netlify emails you as you approach the limit, and on paid plans you can set spending controls from the same place.

The chart is also the quickest way to spot the problem this guide fixes: a single export that deploys on every push shows up as one tall spike in the “number of builds” line, far above your normal weekly rhythm.

Part 4: Test it

1. Confirm the build status is Active builds.
2. Run one export in Simply Static.
3. Open the Deploys tab in Netlify. The thing to check is simple: exactly one deploy for that export, labelled as triggered by the build hook.
4. Check that netlify.toml is still in the repository after the export. It should be, as long as “clear directory before export” is off.

What you will not see is a long column of skipped entries, one per commit. In practice the pushes don’t produce deploy records at all. They never get as far as being listed. Either outcome is fine; the only thing that matters is that one export produces one deploy and the rest of your build minutes stay where they are.

That is worth stressing, because a list of “Skipped” deploys is a different problem, not a sign the fix is working. If you see entries reading skipped due to account credit usage exceeded, as in the screenshot near the top of this guide, your account is out of build credit and nothing is deploying, including the hook.

Compare the build minutes on your usage chart before and after the change. That is the clearest confirmation: same number of exports, a fraction of the minutes.

Troubleshooting