# Every message can tell you its whole story

> A per-message email delivery inspector: full timelines, remote-MX transcripts on the managed lane, and signed, expiring share links for any delivery story.

Canonical: https://emailfast.dev/features/observability

## From "it didn't arrive" to a named cause

The Message Explorer is an email delivery inspector: pick any send and read its full
story — admission, render, queue, each delivery attempt, and the outcome — in one
timeline.

## How it works

1. Find the message in the Explorer and read its timeline end to end.
2. On the managed lane, the Delivery Inspector adds the remote-MX transcript: TLS negotiated, deferrals, the receiving server's verbatim responses, per-hop latency. Full transcript depth arms at launch.
3. Share the story: `/s/:token` links are signed, expiring, and revocable — a redacted, read-only delivery story you can hand to a customer, an auditor, or a receiving postmaster.
4. Ask the deliverability copilot. It's a deterministic diagnosis engine: the same evidence yields the same, named diagnosis, and when the signals don't support a conclusion it says so instead of guessing.

Internally, the platform runs on full Prometheus instrumentation — every subsystem
measured, because owned delivery infrastructure can't be operated blind.

## The evidence

:::panel A delivery story, abridged
```
09:14:03  admitted     idempotency ok, suppression clear, policy pass
09:14:04  rendered     template v7, 41 KB html
09:14:05  attempt 1    mx2.example-isp.com — deferred 421 4.7.28
09:16:19  attempt 2    accepted — 250 2.0.0 OK; TLSv1.3
```
And when a story needs to be proof rather than observability: delivered messages can mint an Ed25519-signed delivery certificate — receiving mail server, TLS details, the server's SMTP response, and timestamps, with the recipient stored only as a keyed hash — chained into a tamper-evident ledger and verifiable without trusting us.
:::

## Honest limits

:::tradeoffs Depth arms at launch, and links are power
Full remote-transcript depth on the managed lane arms at launch with the live
sending path — the timeline works today; the deepest wire detail follows. Share
links are redacted and read-only, but a link is still access: they expire and you
can revoke them, and both properties exist because someone will eventually share one
too widely. The copilot names only what the evidence supports — "unknown" is an
answer it's allowed to give.
:::

## Where to go next

The inspector shows you what the [deliverability engine](/features/deliverability)
is doing;
[proof of delivery](/features/proof-of-delivery) turns a story into a portable
certificate; the [developer door](/developers) covers the API surface it all hangs
off. Postmark's public delivery board is the incumbent benchmark here — the
[comparison](/compare/postmark-alternative) explains what we offer instead.

## What's the difference between the timeline and the transcript?

The timeline is our side of the story: admission, render, queue, attempts, outcome — available for every message. The transcript is the remote server's side, on the managed lane: TLS negotiated, deferrals, verbatim responses, per-hop latency. Full transcript depth arms at launch.

## How safe are share links?

/s/:token links are signed, expiring, and revocable, and they show a redacted, read-only delivery story. They exist so you can hand evidence to a customer or a postmaster without handing them an account.

## Is the deliverability copilot an LLM?

No — it's a deterministic diagnosis engine. The same evidence produces the same, named diagnosis every time, and when the signals don't support a conclusion, it says "unknown" instead of improvising one.

## Can I scrape metrics from the platform?

The platform is instrumented end-to-end with Prometheus internally — that's how we operate it. Per-message answers reach you through the Explorer, the Inspector, and the event stream.