Engineering
Fewer interruptions. Cases that arrive ready to diagnose.
When a customer problem reaches engineering, it should come with what support and DevOps already found. OneOS puts that history in the Jira issue and the Slack thread your engineers already use.
Works in Jira and Slack. In the editor: planned.
PDF render fails over 40 pages
“Our scheduled reports came through as empty PDFs overnight. We send these to our board on Wednesdays.” Ines M. · Quellbrook
- ×Resent the report: still emptyreply 6
- ×Email client ruled out: same empty PDF in two inboxesreply 7
- ×A 10-page report rendersreply 9
- ×Template cache cleared, the fix from #4977: no changereply 11
Datadog Render worker memory alert, 02:11
GCP logs Errors 02:11 to 02:13
“Render limit raised. Helps under 40 pages.”
c41e7a2 Cap render memory (#318) render/pdf/paginate.ts
Messages to Rosa or Dev since 13:30: none
Before you open the code
Start from what's left.
Support and DevOps cross things off as they work the case. OneOS keeps the list, with the reply or message each one came from, so the person who picks it up starts at what's left.
With the history, you start at the last tile. Without it, you start at the first.
Four ruled out, one raised but not fixed, one to start with.
What engineers get today
The whole case, without the meeting.
What the customer reported. What support tried. What DevOps ruled out. The code changes and log errors around the time it started. All linked to their sources.
Support creates the issue from the case with one button. Nothing is created until a person presses it. The issue carries:
- Reported
- In the customer's words
- Already tried
- Each item with the reply it came from
- Around 02:11
- Alerts and log errors
- Dev's note
- From #ops-triage, 09:41
- Related change
- c41e7a2, with its file
- Case timeline
- Five entries, 02:14 to 10:05
Created by OneOS for Rosa · Open case #5230
Your DevOps team already works here. A reply inside an escalation thread is recorded on the case. Anything else in Slack stays in Slack unless a person attaches it.
Render limit raised. Helps under 40 pages.
Where your admin has connected GitHub, commits linked to the case are listed on it, with the file they touch.
Closing the loop
Nobody asks you for an update.
Change the issue, reply in the thread, push the commit. The case shows it, so support doesn't have to ask and you don't have to write it twice.
Status changes in Jira show on the case.
“We know the cause, and a fix is coming.”
Recorded as written, so write what you'd tell the rep.
Where GitHub is connected, linked commits appear on the case.
Access you control
Engineers see the detail. Reps don't.
Raw logs, code and private discussion are visible to engineering and DevOps roles only. Support reps get the summary.
Planned: the case in the editor
Next: the case inside the editor.
We're building an editor extension and an MCP server, so the case history reaches your engineers' editor and coding agents directly. It isn't available yet. We'll tell you when it is.
A panel in the editor (VS Code and similar) for the case history.
Noted. We'll write to you when the editor version is ready.
We won't sell it before it exists.
Outline only. This shows where it would sit, not what it will look like.
Book a walkthrough
Bring a case your engineers had to ask about.
Pick an escalation that reached engineering without enough context. We'll show you what the Jira issue and the Slack thread would have carried.