Our own · Error relayRunning (our own)
Error relay.
The error relay is a Cloudflare Worker that takes Sentry alerts from every OCTYN project and posts them into one Telegram supergroup. Each alert arrives as a short caption with a full-context markdown file attached, so the phone notification is readable and the detail is one tap away. Internal, recorded 2026-07-06.
For your engineering teamInside: error intake · readable summaries · phone alerts with the trace
The relay, drawn.
Running: OCTYN’s own relay. It has no interface, so this is the relay and what it sends to Telegram, on one page. Project names and alert text are samples.
Every error,
in one place.
Each project sends its crash alerts to one small relay. It checks the sender, formats the alert and posts it, with full context, to the one channel the team already watches.
project A
web app · alert rule → webhookproject B
mobile app · alert rule → webhookproject C
api · alert rule → webhooksecret in
the path
Relay
- 01Checks the secret, drops anything else
- 02Reads project, level, message, link
- 03Formats it for a phone, trace attached
- 04Posts to the alerts channel
Slow response on the export route
A job timed out and was retried
Signature check failed on retry
One alert rule pointing at the relay. Nothing else changes.
A test alert confirms the whole path lands, end to end.
One function, then redeploy. Every project picks it up.
In shortEvery error from every OCTYN project arrives on a phone as a short readable line, with the full trace attached as a file.
- Every project reports to one relay.One alert rule per project, pointing at one address.Read how
- The relay checks the secret and drops anything else.Four steps, in one worker.Read how
- Each error lands as a line a lock screen can read.What broke and where, in the one shared channel.Read how
- The full trace rides along as an attached file.The notification stays a notification.Read how
- Nothing tests the pipe on a schedule.If the relay breaks, the alert does not arrive.Read how
The deep dive.
The same relay, taken apart: what each region holds, the rules behind it, one error walked from a project to a phone, and where the path can break.
An error nobody sees is a log.
Errors that arrive somewhere nobody is looking are not alerts. They are a log.
Every OCTYN project reports its errors to one error-tracking service, and that service delivers by email and a dashboard. Both are places a person goes, at a time they choose. That is the wrong shape for the only question an alert has to answer: is something broken right now, while nobody is at the desk. The place that gets looked at within a minute is a phone notification, in the chat app that already carries everything else.
The fiddly part is length. A useful report is a stack trace, a release tag, the request and the environment, far past what a chat message can carry. Cut to fit, a trace looks like information and is not. Sent whole, it buries the one line that needed three seconds under the pages that need three minutes.
The relay, taken apart.
The relay has no screen, so its parts are the three places an error passes: the projects that report, the worker in the middle and the channel on the phone. Here is each, and what it holds.
Three parts, left to right.
The projects that report on the left, the relay in the middle and the channel it posts to on the right. The relay has no interface of its own. This page draws it, with sample project names and sample alert text.
Every error,
in one place.
Each project sends its crash alerts to one small relay. It checks the sender, formats the alert and posts it, with full context, to the one channel the team already watches.
project A
web app · alert rule → webhookproject B
mobile app · alert rule → webhookproject C
api · alert rule → webhooksecret in
the path
Relay
- 01Checks the secret, drops anything else
- 02Reads project, level, message, link
- 03Formats it for a phone, trace attached
- 04Posts to the alerts channel
Slow response on the export route
A job timed out and was retried
Signature check failed on retry
One alert rule pointing at the relay. Nothing else changes.
A test alert confirms the whole path lands, end to end.
One function, then redeploy. Every project picks it up.
- The relay
Three parts, left to right.
The projects that report on the left, the relay in the middle and the channel it posts to on the right. The relay has no interface of its own. This page draws it, with sample project names and sample alert text.
- Left · Projects
Every project, one alert rule.
Each OCTYN project reports its errors to one error-tracking service. Its alert rule posts to the relay's address, with a secret in the path. A new project is one more rule and one more address, and nothing else changes.
Every error,
in one place.Each project sends its crash alerts to one small relay. It checks the sender, formats the alert and posts it, with full context, to the one channel the team already watches.
One alert, end to endsamplePOST /alerts/<secret>project B · errorsecret matchesacceptedformatted · trace attached1 fileposted to AlertsdeliveredProjectserror monitoringproject A
web app · alert rule → webhookproject B
mobile app · alert rule → webhookproject C
api · alert rule → webhook+ any new project: one rule, one URLwebhook
secret in
the pathone postRelay
one worker, every project- 01Checks the secret, drops anything else
- 02Reads project, level, message, link
- 03Formats it for a phone, trace attached
- 04Posts to the alerts channel
Alertsshared channelproject AwarningSlow response on the export route
project CerrorA job timed out and was retried
project BerrorSignature check failed on retry
trace.txtfull traceopen the issueAdding a projectOne alert rule pointing at the relay. Nothing else changes.
Checking the pipeA test alert confirms the whole path lands, end to end.
Changing the formatOne function, then redeploy. Every project picks it up.
- Centre · The relay
One small worker, four steps.
It checks the secret and drops anything else. It reads the project, the level, the message and the link. It formats the alert for a phone, with the trace attached. It posts to the channel. It sits between the tracker's webhook and the chat app's messaging API, and it holds no state.
Every error,
in one place.Each project sends its crash alerts to one small relay. It checks the sender, formats the alert and posts it, with full context, to the one channel the team already watches.
One alert, end to endsamplePOST /alerts/<secret>project B · errorsecret matchesacceptedformatted · trace attached1 fileposted to AlertsdeliveredProjectserror monitoringproject A
web app · alert rule → webhookproject B
mobile app · alert rule → webhookproject C
api · alert rule → webhook+ any new project: one rule, one URLwebhook
secret in
the pathone postRelay
one worker, every project- 01Checks the secret, drops anything else
- 02Reads project, level, message, link
- 03Formats it for a phone, trace attached
- 04Posts to the alerts channel
Alertsshared channelproject AwarningSlow response on the export route
project CerrorA job timed out and was retried
project BerrorSignature check failed on retry
trace.txtfull traceopen the issueAdding a projectOne alert rule pointing at the relay. Nothing else changes.
Checking the pipeA test alert confirms the whole path lands, end to end.
Changing the formatOne function, then redeploy. Every project picks it up.
- Top right · One alert
One alert, four lines.
A sample trail for a single error: the request in, the secret matched, the alert formatted with one file attached, the post delivered. Nothing in the relay times this hop, so the trail has no clock.
Every error,
in one place.Each project sends its crash alerts to one small relay. It checks the sender, formats the alert and posts it, with full context, to the one channel the team already watches.
One alert, end to endsamplePOST /alerts/<secret>project B · errorsecret matchesacceptedformatted · trace attached1 fileposted to AlertsdeliveredProjectserror monitoringproject A
web app · alert rule → webhookproject B
mobile app · alert rule → webhookproject C
api · alert rule → webhook+ any new project: one rule, one URLwebhook
secret in
the pathone postRelay
one worker, every project- 01Checks the secret, drops anything else
- 02Reads project, level, message, link
- 03Formats it for a phone, trace attached
- 04Posts to the alerts channel
Alertsshared channelproject AwarningSlow response on the export route
project CerrorA job timed out and was retried
project BerrorSignature check failed on retry
trace.txtfull traceopen the issueAdding a projectOne alert rule pointing at the relay. Nothing else changes.
Checking the pipeA test alert confirms the whole path lands, end to end.
Changing the formatOne function, then redeploy. Every project picks it up.
- Right · The channel
One group for every project.
A shared group, not a channel each. What matters at a glance is whether anything at all is on fire, and twenty channels would turn one look into twenty. Each line names its project and its level.
Every error,
in one place.Each project sends its crash alerts to one small relay. It checks the sender, formats the alert and posts it, with full context, to the one channel the team already watches.
One alert, end to endsamplePOST /alerts/<secret>project B · errorsecret matchesacceptedformatted · trace attached1 fileposted to AlertsdeliveredProjectserror monitoringproject A
web app · alert rule → webhookproject B
mobile app · alert rule → webhookproject C
api · alert rule → webhook+ any new project: one rule, one URLwebhook
secret in
the pathone postRelay
one worker, every project- 01Checks the secret, drops anything else
- 02Reads project, level, message, link
- 03Formats it for a phone, trace attached
- 04Posts to the alerts channel
Alertsshared channelproject AwarningSlow response on the export route
project CerrorA job timed out and was retried
project BerrorSignature check failed on retry
trace.txtfull traceopen the issueAdding a projectOne alert rule pointing at the relay. Nothing else changes.
Checking the pipeA test alert confirms the whole path lands, end to end.
Changing the formatOne function, then redeploy. Every project picks it up.
- Right · The alert
A caption you can read, a file you can open.
The caption is short and says what broke and where. The full context goes out as an attached file, so the detail is one tap away. The link opens the issue in the error tracker.
Every error,
in one place.Each project sends its crash alerts to one small relay. It checks the sender, formats the alert and posts it, with full context, to the one channel the team already watches.
One alert, end to endsamplePOST /alerts/<secret>project B · errorsecret matchesacceptedformatted · trace attached1 fileposted to AlertsdeliveredProjectserror monitoringproject A
web app · alert rule → webhookproject B
mobile app · alert rule → webhookproject C
api · alert rule → webhook+ any new project: one rule, one URLwebhook
secret in
the pathone postRelay
one worker, every project- 01Checks the secret, drops anything else
- 02Reads project, level, message, link
- 03Formats it for a phone, trace attached
- 04Posts to the alerts channel
Alertsshared channelproject AwarningSlow response on the export route
project CerrorA job timed out and was retried
project BerrorSignature check failed on retry
trace.txtfull traceopen the issueAdding a projectOne alert rule pointing at the relay. Nothing else changes.
Checking the pipeA test alert confirms the whole path lands, end to end.
Changing the formatOne function, then redeploy. Every project picks it up.
- Foot · Notes
What it takes to live with.
Adding a project is one alert rule. A test alert confirms the whole path lands, and nothing sends one on a schedule yet. Changing the format is one function and a redeploy, and every project picks it up.
Every error,
in one place.Each project sends its crash alerts to one small relay. It checks the sender, formats the alert and posts it, with full context, to the one channel the team already watches.
One alert, end to endsamplePOST /alerts/<secret>project B · errorsecret matchesacceptedformatted · trace attached1 fileposted to AlertsdeliveredProjectserror monitoringproject A
web app · alert rule → webhookproject B
mobile app · alert rule → webhookproject C
api · alert rule → webhook+ any new project: one rule, one URLwebhook
secret in
the pathone postRelay
one worker, every project- 01Checks the secret, drops anything else
- 02Reads project, level, message, link
- 03Formats it for a phone, trace attached
- 04Posts to the alerts channel
Alertsshared channelproject AwarningSlow response on the export route
project CerrorA job timed out and was retried
project BerrorSignature check failed on retry
trace.txtfull traceopen the issueAdding a projectOne alert rule pointing at the relay. Nothing else changes.
Checking the pipeA test alert confirms the whole path lands, end to end.
Changing the formatOne function, then redeploy. Every project picks it up.
How the relay does its one job.
This is OCTYN’s own relay, running. These figures draw the rules it is built on, with sample project names and alert text. The write-up records no timing for the hop, so none of the figures has a clock on it.
How an error becomes a line.
- 01Checks the secret, drops anything else
- 02Reads project, level, message, link
- 03Formats it for a phone, trace attached
- 04Posts to the alerts channel
A request arrives from an unknown sender.
Why the trace travels as a file.
Cut here. It reads like a trace and is not one.
Signature check failed on retryproject B · error
The notification stays a notification, and the whole trace is one tap away.
What each failure looks like.
- Error trackergroups and rate-limits
- Relayno database, no queue
- Chat appTelegram
- Phonelock screen
The error tracker still has everything.
One error, from a project to a phone.
A single sample alert through every region. Each step marks what changed on the screen and says what the relay did.
A project reports an error.
Project B's alert rule fires and posts to the relay's address. The secret is in the path. The error is one the tracker has already grouped, so what arrives is an issue, not a raw event.
Every error,
in one place.
Each project sends its crash alerts to one small relay. It checks the sender, formats the alert and posts it, with full context, to the one channel the team already watches.
project A
web app · alert rule → webhookproject B
mobile app · alert rule → webhookproject C
api · alert rule → webhooksecret in
the path
Relay
- 01Checks the secret, drops anything else
- 02Reads project, level, message, link
- 03Formats it for a phone, trace attached
- 04Posts to the alerts channel
Slow response on the export route
A job timed out and was retried
Signature check failed on retry
One alert rule pointing at the relay. Nothing else changes.
A test alert confirms the whole path lands, end to end.
One function, then redeploy. Every project picks it up.
When something in the path breaks.
Every error,
in one place.Each project sends its crash alerts to one small relay. It checks the sender, formats the alert and posts it, with full context, to the one channel the team already watches.
One alert, end to endsamplePOST /alerts/<secret>project B · errorsecret matchesacceptedformatted · trace attached1 fileposted to AlertsdeliveredProjectserror monitoringproject A
web app · alert rule → webhookproject B
mobile app · alert rule → webhookproject C
api · alert rule → webhook+ any new project: one rule, one URLwebhook
secret in
the pathone postRelay
one worker, every project- 01Checks the secret, drops anything else
- 02Reads project, level, message, link
- 03Formats it for a phone, trace attached
- 04Posts to the alerts channel
Alertsshared channelproject AwarningSlow response on the export route
project CerrorA job timed out and was retried
project BerrorSignature check failed on retry
trace.txtfull traceopen the issueAdding a projectOne alert rule pointing at the relay. Nothing else changes.
Checking the pipeA test alert confirms the whole path lands, end to end.
Changing the formatOne function, then redeploy. Every project picks it up.
The relay fails.
The alert does not arrive. There is no second channel and no heartbeat, so a relay silently broken for a week looks exactly like a week with no errors. It is the sort of thing only found during an incident. A periodic test alert is the obvious fix, and it has not been built yet.
Every error,
in one place.Each project sends its crash alerts to one small relay. It checks the sender, formats the alert and posts it, with full context, to the one channel the team already watches.
One alert, end to endsamplePOST /alerts/<secret>project B · errorsecret matchesacceptedformatted · trace attached1 fileposted to AlertsdeliveredProjectserror monitoringproject A
web app · alert rule → webhookproject B
mobile app · alert rule → webhookproject C
api · alert rule → webhook+ any new project: one rule, one URLwebhook
secret in
the pathone postRelay
one worker, every project- 01Checks the secret, drops anything else
- 02Reads project, level, message, link
- 03Formats it for a phone, trace attached
- 04Posts to the alerts channel
Alertsshared channelproject AwarningSlow response on the export route
project CerrorA job timed out and was retried
project BerrorSignature check failed on retry
trace.txtfull traceopen the issueAdding a projectOne alert rule pointing at the relay. Nothing else changes.
Checking the pipeA test alert confirms the whole path lands, end to end.
Changing the formatOne function, then redeploy. Every project picks it up.
The chat app is unavailable.
The same holds, with one mitigation: the error tracker still has everything. Nothing is lost, only the speed of finding out.
Every error,
in one place.Each project sends its crash alerts to one small relay. It checks the sender, formats the alert and posts it, with full context, to the one channel the team already watches.
One alert, end to endsamplePOST /alerts/<secret>project B · errorsecret matchesacceptedformatted · trace attached1 fileposted to AlertsdeliveredProjectserror monitoringproject A
web app · alert rule → webhookproject B
mobile app · alert rule → webhookproject C
api · alert rule → webhook+ any new project: one rule, one URLwebhook
secret in
the pathone postRelay
one worker, every project- 01Checks the secret, drops anything else
- 02Reads project, level, message, link
- 03Formats it for a phone, trace attached
- 04Posts to the alerts channel
Alertsshared channelproject AwarningSlow response on the export route
project CerrorA job timed out and was retried
project BerrorSignature check failed on retry
trace.txtfull traceopen the issueAdding a projectOne alert rule pointing at the relay. Nothing else changes.
Checking the pipeA test alert confirms the whole path lands, end to end.
Changing the formatOne function, then redeploy. Every project picks it up.
A payload that will not parse.
The caption is generated from fields, not from the trace. A trace that cannot be parsed, or one that is oversized, still produces a readable notification. The attached file may be ugly.
What it does, and what is not measured.
- Recorded
- Covers every project OCTYN runs. Recorded internal, 6 July 2026, with no public surface.
- Not measured
- There is no timing on the hop. That an error reaches a phone in seconds is a wall-clock observation, not an instrumented figure, and it is published as that. Nothing records how long the tracker, the relay or delivery took.
- Under load
- The error tracker groups and rate-limits on its own side, so what arrives is distinct issues, not raw events. Volume has not been a problem, and the reason is structural.
- The line it holds
- It relays and does not remember. There is no database, no queue and no state to drift.
- Where it runs
- As a small, independent relay, on infrastructure that is none of the things it watches. An alert path that depends on the servers it watches goes quiet exactly when those servers are the problem.
- Who keeps it up
- Nobody, most of the time. What maintenance it needs is triggered from outside: a change in the tracker's webhook payload, or in a messaging limit. Its real cost is attention, because a system nobody tests is trusted more than it has earned.
- When requirements change
- Which projects report, and where they land, is configuration with no deploy. Routing by severity, a destination per project or a quiet window overnight is a small code change. Anything that must remember, such as acknowledgement or escalation, needs state, and that is the moment it stops being a relay. Replying to an alert to restart something is a rebuild, because a chat group that can act on production is a credential.
- What we would do differently
- Send a heartbeat, and time the hop. Everything else here is right, and these are the two claims with nothing behind them.
- Left out
- Project names and alert text on the screen are samples.
Something like this, for your company?
The first conversation is with the people who would build it. If there is a fit, the Consult comes next.