Support center
Every way to get help with the platform we delivered, in one place: the documentation set, the day-2 procedures, the troubleshooting method, the service levels and the people.
What support means here
BuiltForProd support is help with the platform we built and handed over: the cloud foundation, the Blueprints deployed on it, the pipelines that change it and the documentation that explains it. It has four layers, and most questions are answered by the first two. The documentation set on docs.builtforprod.com is personalized to your organization. The day-2 procedures are written for your team to run without us. Troubleshooting entries are organized by symptom. Engineers are the last layer, reached through BuiltForProd Managed.
Everything below is available to you whether or not you hold a Managed tier. What a Managed tier adds is people and, in one tier, a response commitment.
What do you need?
Six doors. Pick the one that matches the sentence you would type into a chat window.
I need the documentation
Your documentation set is on docs.builtforprod.com, personalized to your namespace, domains, region and account ids.
I need to run a procedure
Deploying a change, promoting to production, rolling back, rotating a secret, adding an account or a region, scaling a stage.
Something is broken
Start from the symptom. Every troubleshooting entry names the cause, the fix and the prevention.
Production is down
Open the request in writing first, state the impact and the stage, then start the call. A written request is what the clock runs from.
A question about billing or purchasing
Deployment tiers, Managed tiers, invoices and AWS Marketplace private offers are answered in the FAQ.
A security question or report
Security questionnaires, reviewer evidence and vulnerability reports go to [email protected], with "Security" in the subject line.
The three Managed tiers
Support tiers are the tiers of BuiltForProd Managed. All three are optional and post-deployment.
| Tier | What it covers | Commitment | Best for |
|---|---|---|---|
| On-Demand | Consultation and support by the hour, when you ask for it. | Pay per hour, minimum 10 hours. Best effort, no response commitment. | A team that owns the platform and wants an expert for the occasional problem. |
| Support SLA | The same engineers, governed by the service levels in your agreement. | A pre-paid annual block of at least 100 hours, expiring after one year. | A team that needs guaranteed responsiveness and a predictable budget. |
| Team Augmentation | Dedicated engineers working inside your team, on your priorities. | Part-time (4 hours a day) or full-time (8 hours a day), for 6 or 12 months, billed monthly. | An organization where production matters but nobody owns it full-time. |
Service levels sets out the escalation path, how severity is used and what falls outside support. Pricing explains how an engagement is quoted.
Channels
The same three channels serve every tier.
| Channel | Use it for |
|---|---|
| Anything that needs a record: a new request, a question with attachments, a change of scope. | |
| Slack | Day-to-day conversation, quick questions and incident coordination, under Support SLA and Team Augmentation. |
| Video | Working sessions, reviews and incident bridges. |
Open every incident in writing
Start a call if you need one, but open the request in writing as well. The written request carries the timestamp that any response commitment runs from, and it survives the shift change.
What to include in a support request
An engineer can act immediately when the request carries the facts the platform already produces.
Impact and severity
Which stage (sandbox, dev, staging, prod), what users see, since when, and the severity you believe applies.
Repository and change
The repository, the pull request or commit, and whether the change was applied or is still at the plan stage.
The workflow run
A link to the GitHub Actions run, with the run report artifact attached. It lists every unit with its result and reason, which reads faster than the log.
The plan or the error
The relevant part of the plan output or the error message, as text rather than a screenshot.
What already changed
Any console action, drift issue or manual step taken during the incident, so the engineer knows where the code and the environment disagree.
Account and region
The account name and the region. Never credentials, keys, tokens or decrypted secrets.
The same checklist lives in the documentation, under contacting support.
Before you open a ticket
-
Check the drift issues. Drift detection opens a GitHub issue labeled
driftwhen an account's plan is not empty. If one is open on the account you are looking at, read it first. - Read the run report. Every plan and apply run attaches a report artifact listing each unit with its result and the reason. It is faster to read than the raw log.
- Open the troubleshooting section. Each documentation page about a component ends with the symptoms that component produces, and what each one means.
- Check the upgrade guide. If the problem appeared after pulling upstream changes, the upgrade guides say what that change moved.
The rest of the support center
Getting started
What happens after purchase, what we need from you, and what done looks like.
Knowledge base
What documentation exists, how it is organized, and how to get access.
How-to guides
The day-2 procedures your team runs without us.
Troubleshooting
Symptom, cause, fix, prevention, and what to check before opening a ticket.
FAQ
Straight answers to the questions we are asked most.
Service levels
The three Managed tiers, the escalation path and what is not covered.
Product documentation lives on docs.builtforprod.com. Purchasing and licensing terms are on purchasing and licensing, and the website's own terms are under legal.
Support questions
Does a Baseline purchase include ongoing support?
A Baseline or Blueprint purchase is a one-time deployment that hands over the repositories and the documentation, and ongoing support is a separate, optional service called BuiltForProd Managed. You receive the full documentation set, the customized repositories and the handover session whether or not you buy a Managed tier.
How do I reach BuiltForProd support?
BuiltForProd support uses three channels for every Managed tier: email, Slack and video conferencing. The addresses, the Slack workspace and the meeting details are given to you when your engagement starts, so they are not published here.
What should I check before opening a support request?
Check the drift issues in your repository, the failed workflow run and its run report, and the troubleshooting section of the page that covers the component. Those three sources resolve most problems without a ticket, and if they do not, the facts you gathered are exactly what the request needs.
Can BuiltForProd engineers change my production directly?
No. Under Managed, BuiltForProd engineers work through your own pull requests, plan workflow, code-owner review and production environment gate, exactly as your team does. The pipeline stays the only writer, and your access removal ends theirs.
What does support not cover?
Support covers the platform BuiltForProd delivered: the landing zone, the Blueprints, the pipelines and the documentation. It does not cover cloud provider availability, and it does not cover the availability of your own application; when the root cause is application code, product design or a data model, we will say so.
Not sure which door to use?
Tell us what is happening and which stage it is happening in. If it is an incident, open it in writing first, then start the call.