You apply.
Name the journeys that would hurt most. If we can help, we propose a call. If we can't, we say so.
Next stepApplication confirmation
DESIGN-PARTNER PROGRAM · SYNTHETICS + AI SRE
We install it. You get paged with a reason.
We write Playwright checks for the 3–5 journeys that cost you money when they break, wire them to your alerts, and add an agent that tells you whether a failure is your code or a vendor.
- Set up for you.We write the checks with you, or run the Playwright specs you already have. Failures alert the channel you already use: Slack, PagerDuty, Microsoft Teams or 17 other integrations.
- Email and webhook steps included.Signup emails and checkout webhooks are checked in the same run: a private inbox, a webhook URL, and a wait for the message to arrive.
- Your code or your vendor.Every failure arrives with the evidence and a verdict, not just "checkout failing".
4 regionsfailure evidence kept 14 days2,000+ vendor status feeds3–5 journeys per partner
HOW IT RUNS
The setup is our job. Not yours.
The program runs 8 weeks. Your part: one 30-minute call, one pull-request review, a test account and 15 minutes a week. We do the rest.
1 2 30-minute call.
We pick the 3–5 journeys that would hurt most and agree how to log in: a dedicated test user, never your admin.
Call30-minute call3 We build the checks.
Playwright specs in a pull request to your repo, or on our side if you prefer. You review them like any other code.
Pull requestAdd Playwright checks: signup, login, checkout4 Alerts and the agent go live.
Checks run on schedule, failures page the channel you chose, and the AI SRE agent investigates every failure.
Example alertcheckout-pro-plan failed in eu-west and ap-south5 Weekly check-in, review at week 4.
15 minutes a week: you tell us what was noisy and what was missing, and we change it. At week 4 we look at what the checks and the agent caught; either side can stop there.
Next stepweekly check-in · 15 min
SAMPLE REPORT
A failed checkout, explained. In one screen.
What lands in the incident when a journey fails: the step, the evidence and a verdict on whose problem it is. Two illustrative investigations using fictional Acme data: one vendor failure and one code failure.
Every report includes
- The failing step, with the screenshot and trace at that moment
- The network and console lines that matter, not the whole log
- What your vendors' status pages said at that moment
- Which of your other journeys passed in the same window
- A plain verdict: your code, a vendor, or unclear, and what it couldn't determine
FIT
Who this is for. And who should wait.
We have room for a few teams. We'd rather say no early than install something that doesn't help.
Strong fit when
- You're a 3–30 engineer SaaS or API company with a signup, login or checkout that customers would notice breaking.
- You depend on third parties (Stripe, Auth0, an email provider) and have lost time deciding whether a failure was yours.
- Nobody on the team is a dedicated SRE and nobody wants to become one.
- A customer has reported an outage before you noticed, at least once in the last 90 days.
- Someone on the team can review the checks we write and tell us each week what was noisy.
Not yet when
- You need probes inside a private network. We run from four public regions only.
- You need a SOC 2 report today. We don't hold one; we answer security questionnaires directly.
- You only want Synthetics, without the setup. Book a demo and we'll open it on your workspace.
- You expect an agent that fixes things on its own. Ours investigates and reports.
- You already have a platform team, an on-call rota and a synthetic monitoring tool you're happy with.
ACCESS AND DATA
Where your checks run. What we keep.
The facts a security-minded CTO asks for on the first call. The full list is on our security page.
- Where checks run
- Each run executes in its own gVisor sandbox with no route to internal networks, from four regions: us-east, us-west, eu-west, ap-south.
- Secrets in specs
- Encrypted with AES-256-GCM under a per-workspace key wrapped by AWS KMS. They reach your spec as environment variables and are masked in network logs, HAR and console. Anything shown on screen can appear in the screenshot and video, so use a test account.
- What a failed run keeps
- Screenshot, video, Playwright trace, network log (HAR) and console, for 14 days.
Facts checked 6 Oct 2026
Questions you'd ask before applying
What is the DevHelm design-partner program?
A small program where the DevHelm team sets up Synthetics, alerting and the AI SRE agent on your critical journeys, tunes them with you, and asks for weekly feedback in return.
What does it cost?
Terms depend on scope. We cover them on the first call, before anything is set up.
Do I need Datadog, OpenTelemetry or any observability stack?
No. The checks run from outside your infrastructure, and the agent starts from what they and your vendors report. Logs and traces help if you have them; they aren't required.
Can you use the Playwright tests we already have?
Yes. Synthetics runs real Playwright with your own specs. If you don't have any, we write them with you.
What does the AI SRE agent actually do?
When a run or check fails, or a vendor reports an incident, it investigates and tells you what broke and whether it looks like your code or a vendor, with the evidence. It doesn't deploy, roll back or change anything in your systems.
Is this production-ready?
Synthetics is in beta and the agent is only available to design partners, which is why we set it up and watch it with you. We'll tell you what we saw break.
What do you get out of it?
Weekly feedback, and, if it works for you, a case study. You approve every word, and we never use your name or logo without written permission.
How long does the program run?
8 weeks. Week 1 is setup, weeks 2–4 are tuning, and at week 4 we review what the checks and the agent caught. Either side can stop there. Weeks 5–8 are steady running, long enough that a real failure or vendor incident usually lands and you see how the report reads.
What happens after week 8?
You move to a paid plan and keep the checks running, or you stop and keep the Playwright specs, which live in your repo.
What if you can't help us?
We'll say so in our first reply and point you to a free Uptime account or a Synthetics demo instead.
Tell us which journey would hurt most.
We reply to every application and tell you whether we can help, and what we'd set up first.
- 3–5 journeys
- Weekly 15-minute check-in
- The DevHelm team writes your first checks