This policy exists because a government customer asks for it in writing, and because a small operation needs a written rule for which problems get answered immediately and which wait for the next business day. It is deliberately conservative. It promises only what can actually be delivered, and it is calibrated against measured system behaviour rather than design intent.
Relationship to the Terms of Service. The Terms provide the platform "as is" and "as available" and disclaim warranties, including continued availability of the Meta Marketing API. Nothing here creates a contractual service level. This is an operational commitment, published so customers can plan.
1. Severity Definitions
Severity is set by consequence, not by how loud the report is.
| Severity | Definition | Examples |
|---|---|---|
| S1 | Money is wrong, or one customer can see another's data. Unrecoverable or hard to reverse. | Credits charged and not delivered. A campaign spending past its funded balance. Any cross-organization data exposure. Ledger and balance disagree. |
| S2 | A customer cannot do the core job, and there is no workaround. | Publishing fails for every campaign in an organization. Login is down. Credit purchase fails at checkout. |
| S3 | A feature is broken or degraded, with a workaround or a tolerable delay. | Delivery metrics stale beyond a day. PDF report generation failing. Ad previews not refreshing. |
| S4 | Cosmetic, informational, or a feature request. | Wrong label. A chart axis. A request for a new capability. |
A campaign with a fixed event date inside the next 7 days that cannot publish is S2 regardless of cause, including when the cause is Meta rather than Formation Ads. Time-boxed event campaigns are the product's whole point, and a Meta outage is still the customer's problem.
2. Response and Resolution Targets
"Acknowledge" means a human acknowledgement with an assessment, not a fix. Business hours are 09:00 to 18:00 US Eastern, weekdays.
| Severity | Acknowledge | Mitigate or work around | Resolve |
|---|---|---|---|
| S1 | 4 hours, any day | 24 hours | 3 business days |
| S2 | 1 business day | 3 business days | 10 business days |
| S3 | 3 business days | Best effort | Next scheduled work |
| S4 | 5 business days | Not applicable | No commitment |
These are targets, not guarantees, and they assume the operator is reachable. See section 5 for what happens otherwise.
Money is always mitigated before it is resolved. For any S1 involving credits, the immediate action is to make the customer whole (adjust the balance, refund, or freeze spend) and then diagnose. The credit ledger is append-only, every correction is an adjustment entry with a written reason, and both sides appear in the customer's own audit log.
3. What to Expect When Something Breaks
- A broken feature usually stays broken until one person fixes it. There is no second engineer and no overnight rotation. For S3 that can mean days.
- An outage affecting one organization does not affect the others. The publish queue, the failure circuit breaker, and every scheduled job are scoped per organization. One organization's expired Meta token, failed campaign, or bad data cannot stall another's work.
- Spending cannot run away. An organization cannot spend more than the credits it has purchased, and every ad object is created paused, so a failure in the publishing pipeline produces a campaign that does not run rather than one that overspends.
- Nothing is silently deleted. The credit ledger is append-only and the audit log records every change with the acting user.
4. Communication
- Contact: support@formationads.com. Signed-in users can also send feedback from inside the app; S1 and S2 reports should still go by email. There is no phone line.
- S1 and S2 incidents affecting a customer get a proactive notice, including when Formation Ads found the problem first. The notice says what happened, what the customer should do, and when the next update comes.
- Post-incident note within 5 business days for every S1, including cause and what changed so it does not recur.
- Planned maintenance is announced at least 2 business days ahead. Deploys are zero-downtime, so there is no standing maintenance window.
5. Continuity When the Operator Is Unavailable
This is the honest weak point and it is named rather than hidden.
- Break-glass operator. A named non-developer holds credentials and a written runbook covering: roll back a deploy, disable scheduled jobs, disable the payment webhook, and send a status notice to customers. That is enough to stop a bad situation getting worse. Until this person is named and the runbook is written, the continuity commitment is not met.
- Planned absence over 48 hours is announced to active customers in advance, with the coverage arrangement stated.
- Unplanned absence. S1 mitigation falls to the break-glass operator, whose scope is limited to stopping loss, not fixing code.
6. Known Limitations, Stated Up Front
- Third-party dependency. Campaign delivery depends on the Meta Marketing API and on the customer's Meta account standing. Meta outages, ad rejections, policy actions, and account restrictions are outside Formation Ads' control and are reported, not fixed.
- Data recovery window. Database point-in-time recovery is currently 6 hours, with a weekly encrypted export as the independent backup. This is being changed to a 7-day window. Until that ships, corruption discovered more than 6 hours after the fact may not be fully recoverable from the database alone.
- Scheduled-job timing. Background jobs (delivery metric refresh, financial reconciliation, token health) run on a scheduler that delivers a fraction of its nominal ticks. Jobs are dispatched by what is overdue, so a missed tick is caught up by the next one that arrives, but metrics can be staler than the nominal cadence suggests. This does not affect campaign delivery, which Meta runs, or spending limits, which are enforced at the ad-account level.
- Support hours. A small operation, US Eastern, with other commitments.
7. Review
Reviewed at first customer signature, then quarterly, and after every S1. The limitations in section 6 are removal triggers: if one is still present at the next quarterly review, that is the finding.
Related: Security, Subprocessors, Accessibility Conformance Report.