Standing service app-keep-critical-flows-working · revised 11 October 2026
Standing service
Keep your web app's sign-in, forms and integrations working, month after month
We run agreed checks of up to four critical flows against a test account every week. When one breaks we investigate and open a fix pull request, or tell you what only you can change.
This starts a conversation by email. Nothing is charged, and nothing is checked, until we have agreed scope and terms with you in writing.
The responsibility you hand over
The flows that earn or retain customers are usually the least often tested by the people who build them. A provider change, an expired setting, a library update or a proxy change can break one quietly. The first sign is a complaint, long after the break.
Who it’s for: A founder or product owner whose app has a few flows that must work (sign-in, a lead or signup form, an incoming webhook) and who currently finds out they broke when a customer complains.
Usually starts when: A change to hosting, a library or a provider setting broke sign-in or a form without anyone noticing for days, or releases are frequent and nobody tries the main flows afterwards.
The result: Up to four named flows are checked every week with a test account against the environment you agree. A break is investigated and ends in a fix pull request or an explanation, and each month you see which checks passed, which failed and how each failure ended.
What stays true, and what we do about it
No response-time guarantee is published for this new service. A target is agreed in writing before it starts, set to what a service at this stage can keep.
Hours are agreed in writing before the service starts. The service is not staffed round the clock and offers no out-of-hours cover.
What must remain true
- The named flows complete successfully with a test account in the agreed environment
- Every failed check is investigated and ends in a fix pull request or an explanation
What we watch
- Results of the weekly automated checks
- Your release notes or deployment dates, where you share them
- Provider messages or notices you forward to us
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| A sign-in check fails at the redirect request the app builds, or at the stubbed or test-mode provider return. | We trace one test sign-in on a branch and open a pull request that fixes the callback, or tell you what the provider console needs. A fault that appears only on the provider's real sign-in page cannot be caught by these checks. Priced as: Fix a sign-in callback error |
| A sign-in check passes but the next page treats the test user as signed out. | We trace the session cookie on a branch and open a pull request that fixes it, or tell you what the proxy or host needs. Priced as: Fix a login that does not stick |
| An incoming-event check is rejected by your endpoint as unsigned. | We compare the endpoint with the provider's documented signature scheme and open a pull request that fixes it. Priced as: Fix webhook signature checks |
| A form check shows genuine test submissions refused or junk test submissions accepted. | We fix the form's server rules and test sets with a pull request. Priced as: Stop form spam, keep real enquiries |
| A release you have told us about goes out, within the four release checks a month. | We run every named flow once and tell you whether any check failed. Releases beyond the fourth in a month are covered by the next weekly run, or under a larger agreed scope. |
| A month ends. | We send a short written summary: every check, every failure, how each ended and what is still open. |
We do on our own
- Run the agreed checks with the test account
- Reproduce and investigate failures on a branch
- Open pull requests that change code, tests or configuration files in the repository
We ask you first
- Anything that changes secrets, provider accounts, hosting or proxy settings
- Merging, or any change to your production environment
- Adding a new check that touches payments, messages or real data
- Adding a stubbed or test-mode provider return to the app, which changes the code you deploy
We escalate to you when
- The cause is outside your code, such as a provider setting, a host or an outage
- A fix would change what your product does, not only restore what it did
- Failures pass the agreed monthly number
- Releases you tell us about pass four in a month
How you know it held. Each month you get every check with its result and how each failure ended, and a passing run of the failed check is the evidence for each fix.
How we keep it true
This service is never finished. Each month's summary shows whether the named flows kept passing, and it continues until you end it.
Fix one social sign-in that fails with a redirect or callback error Job Each time it fires
One named sign-in provider completes login in the environments we agree: the provider accepts the callback and your app starts a signed-in session. You review and release the change.
Within the agreed monthly number
A broken sign-in callback is fixed the same way as the one-off job.
Fix users being logged out straight after a successful login Job Each time it fires
After login, a test user stays signed in across page loads in the agreed environments, and across a browser restart where a lasting session is agreed. The cookie is set, sent back and kept.
Within the agreed monthly number
A login that does not stick is fixed the same way as the one-off job.
Fix one webhook endpoint that rejects genuine events as unsigned Job Each time it fires
One named provider's test events pass signature verification at your endpoint, and forged or altered events are rejected. You review and release the change.
Within the agreed monthly number
A rejected incoming event is fixed the same way as the one-off job.
Stop junk submissions on one web form without blocking real people Job Optional
One named form rejects a fixed set of junk submissions on the server and still accepts a fixed set of genuine ones, including unusual names and addresses. You review and release the change.
Offered when a form check shows a validation or junk problem.
What is included, and what is not
- The agreed checks, written so that you can run them yourself
- A fix pull request with a passing check for each failure we can fix within the agreed number
- An explanation of what you need to change, when the cause is not in your code
- A written monthly summary
Included
- Weekly automated checks of up to four named flows, using a test account, one environment and no real customer data
- A release check after a release you tell us about, up to four release checks a month (one release check is one run of every named flow)
- For a flow that signs in through an outside provider (for example Google or GitHub), the automated check goes as far as the address the app sends the user to and a stubbed or test-mode provider return that your app can accept in the agreed environment; it never drives the provider's own sign-in page
- Investigation of each failed check on a branch, and a fix pull request for each cause we can fix, up to the agreed number a month
- A plain explanation, with evidence, when the cause is outside your code, such as an expired provider setting or an outage
- A written monthly summary of every check and what happened to each failure
Not included
- Merging, deploying or changing provider accounts, secrets or hosting, which stay with your team
- Checks that make real payments, send real messages to customers or change real customer data
- Round-the-clock monitoring, paging or any guaranteed response time
- New features, redesigns or flows beyond the four named
- Security testing, penetration testing or monitoring for attacks
- Fixing outages or faults inside a third-party service
- Scripted sign-in through a provider's own sign-in page, or checks that use real provider accounts, which the provider may block and its terms may not allow
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each week every named flow has a recorded check result, and each failed result links to its investigation. For a flow that signs in through an outside provider, the result covers the redirect address the app builds and the stubbed or test-mode return only; it does not show that the provider's own sign-in page works.
Evidence: The weekly check log and the monthly summary.
For each fix, the failed check passes on the pull request branch against the agreed environment.
Evidence: Links to the failing and passing check runs.
No file outside those named in each pull request is changed, and no real customer data is used by any check.
Evidence: The pull request diff and the check definitions.
Sign-off. You review and merge each pull request, and you read each monthly summary. A fix counts as delivered when you accept it.
If it fails. If we cannot fix a failure, we say so, explain what we found and what it would take, and it does not count against the monthly number. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- You can create a test account, and a staging environment or a clearly separated test area, for the checks to use
- The flows can be exercised without charging money, emailing real customers or altering real data
- The source can be inspected through an agreed route, with pull requests that a person on your side reviews
We stop and tell you if
- The flows can only be checked with real customer accounts, real payments or production secrets we would have to hold
- Most failures are caused by something outside your code that you cannot or will not fix
- Failures regularly exceed the agreed monthly number, so we agree a different scope
- Releases regularly pass four a month, so a different scope is agreed
What could go wrong
Every fix is a pull request that your team merges, so you can revert it as you would any other change. Ending the service leaves your app as it is; the checks are yours to keep or delete.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A check changes real data or messages real customers. | Checks use a test account and a separated environment, never real payments or real recipients, and a new check touching those needs your written approval. |
| A fix makes a check pass by weakening what it checks. | We change what is broken, not what the check demands, and you review and merge every pull request. |
| A test account gives us more access than you intended. | The account is yours, has no real customer data and can be revoked at any time. |
Each pull request is checked by a reviewer separate from the work that produced it before it is opened. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- You review and merge every pull request
- You approve any change to secrets, accounts, hosting or proxy settings
Access we would need
- A test account you create and can revoke
- A staging address or clearly separated test area
- Access to a fork or branch for pull requests
Questions
How is this different from the one-off repairs?
A one-off repair fixes one broken flow once. This watches the flows you name every week and takes each failure through to a pull request or an explanation.
Do the checks log in through Google or GitHub for real?
No. Providers can block scripted sign-in and may not allow it. The check covers the address your app sends users to and a stubbed or test-mode return, so a fault only on the provider's real page is not caught; your own person can still try it by hand.
Do the checks touch real customers?
No. They use a test account in an environment you choose and never make real payments or message real customers.
Is this uptime monitoring?
No. It checks that specific flows complete, once a week and after up to four releases a month. There is no round-the-clock cover or response-time guarantee.
Send an enquiry
Send us
- The four flows you most need to keep working, in order of importance
- The address of the environment where they can be checked safely
- Who reviews and merges pull requests
Later, once you agree
- A test account for each flow, whose password you can change at any time, and a staging address
- Source access through an agreed company-controlled route, with a branch or fork for pull requests
- The agreed number of fixes a month, who to tell when something is outside your code and what each check should prove
- For any outside-provider sign-in, a test-mode provider app or a way to feed your app a stubbed return in the agreed environment, or your agreement that it is checked by hand
You own the app, the accounts and the secrets. We use a test account you create and can revoke, against an environment you choose, and we change files only through pull requests your team reviews and merges. We hold no customer data.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “app-keep-critical-flows-working” as the subject.