There is motion at your front door. That is the whole message. A white rounded notification banner with a bell icon, then a circular, green-tinted view of an orange tabby pressed so close to the lens that its face fills the frame. Porch siding and lights sit behind it. The shirt is a joke about a doorbell camera, but the joke works because the notification is doing exactly what a notification should do: it tells you something happened, not what it means.
I keep coming back to that gap. The banner is a model of terse, accurate reporting. The image underneath is the part that makes you laugh, and it is also the part the banner cannot describe. That is the same gap I see in API contracts every week, and it is where most of the arguments start.
What the artwork actually shows
Look at the composition before you read anything into it. The banner is a UI element, not a sentence someone typed. It has a bell, a rounded rectangle, and a single line of text. The camera view is circular, tinted green, and framed like a peephole. The cat is not sitting politely on the mat. It is close enough that the lens is doing the thing doorbell cameras do when a subject ignores the intended distance.
That is the visual joke: the system reported motion, and the motion turned out to be a cat committing a boundary violation with its face. The shirt does not say the cat rang the bell. It does not say the cat is welcome. It says motion was detected. Everything else is interpretation.
I am reading the design, not claiming a history for it. The wording is a common doorbell-camera phrase, and the shirt uses it as a caption for the image below. The humor comes from the mismatch between the flatness of the alert and the specificity of the cat.
The alert is a contract, and the image is the payload
In API terms, the banner is the status line and the camera view is the response body. The banner tells you a condition was met. The body tells you what the condition actually looked like. A good contract does both without pretending the status line can carry the whole story.
Here is the failure mode I see most often: a team writes an error response that says something like {"error": "invalid request"} and considers the contract done. The status code is correct. The message is technically true. And the person debugging at 2 a.m. has no idea whether the problem is a missing field, a bad token, or a payload that was too large. The alert fired. The image is missing.
The doorbell shirt is funny because the image is absurd, but the structure is sound. The banner does not try to describe the cat. It reports the event. The camera view supplies the detail. If the banner had said “a large orange cat is too close to the lens,” it would be a worse notification and a worse joke.
Where terse messages go wrong
Terse is not the same as complete. The banner works because the camera view is right there. In an API, the equivalent of the camera view is the error detail, the request ID, the field path, and the link to the docs. Strip those out and you have a notification that is accurate and useless.
I have watched teams argue about this for an entire sprint. One side wants short error messages because they are easier to log. The other side wants detail because support tickets keep arriving with screenshots of the short message and nothing else. Both sides are right about their own problem and wrong about the contract. The message is not the whole response. The response is the banner plus the payload.
A useful pattern is to separate the machine-readable code from the human-readable explanation and the debugging context. The code is the banner. The explanation is the caption. The context is the camera view. If any of those is missing, someone downstream pays for it.
The cat is the unhandled case
Doorbell cameras are designed for people. The motion alert assumes a delivery driver, a neighbor, a package. The cat is the case the system did not model, and the joke lands because the system still reported it correctly. Motion is motion. The camera did its job. The human looking at the phone has to decide what to do about it.
That is a useful way to think about error paths. Most teams test the happy path and the obvious failures. The cat is the request that arrives with an unexpected shape, the webhook that fires twice, the retry that lands after the original succeeded. The contract does not need to predict the cat. It needs to report the motion accurately and give the reader enough to act.
Imagine a partner sends a null where you expected a string, and your error response says “bad request” with no field name. The banner fired. The camera view was a blank circle. The fix is not to make the banner longer. The fix is to add the field-level detail that tells the caller where to look. That is the difference between reporting the event and reporting the evidence.
What the shirt argues, and what it does not
The shirt argues that a flat notification plus a specific image is a complete joke. It does not argue that flat notifications are good API design. Those are different claims. The joke depends on the reader supplying the context, and the reader can see the cat. An API consumer cannot see your database.
So the lesson is not “be terse.” The lesson is “know which part of your message is the banner and which part is the camera view, and do not ship one without the other.” The banner is the event. The camera view is the evidence. A contract that reports the event without the evidence is a doorbell that rings and shows you a gray circle.
If you want the object itself, the shirt is the There Is Motion At Your Front Door shirt from Quirky Cotton Collective. It is a visual joke about a doorbell camera, and it is a decent reminder that the alert is never the whole story.
A small checklist for the next error response you write
- Name the event. The status code and error code should tell the caller what happened without requiring them to parse prose.
- Supply the evidence. Include the field path, the offending value if it is safe to echo, and a request ID that ties the response to your logs.
- Separate the banner from the caption. Keep the machine-readable code stable and the human-readable message free to change.
- Test the cat. Write one test for the unexpected shape, not just the documented failure.
- Check the view. If your error response would look like a gray circle to someone who did not write the code, add context until it does not.
The doorbell shirt gets the structure right. The banner reports the motion. The camera shows the cat. The joke is that the cat is the whole story, and the banner never claimed otherwise. Your error responses can learn from that, as long as you remember that your callers cannot see your porch.
Editorial note: This publication and Quirky Cotton Collective share an owner.